Hi Daniel.
I am using mysql version 5.0.37, compiled on 64 bits too.
These are the printing of the symbols you asked:
(gdb) print row
$1 = (db_row_t *) 0x10026bf68
(gdb) print ROW_VALUES(row)
No symbol "ROW_VALUES" in current context.
(gdb) print VAL_NULL(ROW_VALUES(row)
No symbol "VAL_NULL" in current context.
(gdb)
Thanks.
Hello Sergio,
seems to be some data corrupted from what database returned. What is the
database type you use, mysql?
Could you print the the content of row and ROW_VALUES(row) (via print
command in gdb)?
Thanks,
Daniel
On 03/26/07 23:46, Sergio Gutierrez wrote:
> Hi again Daniel.
>
> Testing other things trying to solve the problem I found that the
> segmentation fault occurs when Openser is restarted and there are
> records within location database table.
> If the table is empty initially, openser starts OK, and users can
> register without problem.
>
> Below is the backtrace of a error when the location table is not empty:
>
> #0 0xffffffff7d90e2a0 in preload_udomain (_c=0x10026ad90,
> _d=0xffffffff5028e9f0) at udomain.c:404
> 404 if (VAL_NULL(ROW_VALUES(row))
> (gdb) bt
> #0 0xffffffff7d90e2a0 in preload_udomain (_c=0x10026ad90,
> _d=0xffffffff5028e9f0) at udomain.c:404
> #1 0xffffffff7d915844 in child_init (_rank=1) at ul_mod.c:344
> #2 0x0000000100082500 in init_mod_child (m=0x1, rank=1,
> type=0x1000f41b0 "CHILD") at
> /home/operador/openser-1.2.0-notls//sr_module.c:400
> #3 0x0000000100082460 in init_mod_child (m=0x1, rank=1,
> type=0x1000f41b0 "CHILD") at
> /home/operador/openser-1.2.0-notls//sr_module.c:394
> #4 0x0000000100082460 in init_mod_child (m=0x1, rank=1,
> type=0x1000f41b0 "CHILD") at
> /home/operador/openser-1.2.0-notls//sr_module.c:394
> #5 0x0000000100082770 in init_child (rank=1) at
> /home/operador/openser-1.2.0-notls//sr_module.c:394
> #6 0x0000000100032414 in main_loop () at
> /home/operador/openser-1.2.0-notls//main.c:724
> #7 0x00000001000345a4 in main (argc=2, argv=0xffffff7eaeeec4ff) at
> /home/operador/openser-1.2.0-notls//main.c:1399
>
>
> Thanks.
>
>
>
>
>
> On 3/26/07, *Sergio Gutierrez* <saguti@gmail.com
> <mailto:saguti@gmail.com>> wrote:
>
> Hi Daniel.
>
> This is the backtrace of the core.
> Thanks
>
> #0 0xffffffff7d90ee9c in preload_udomain (_c=0x10026b7d800,
> _d=0x0) at
> /home/operador/openser- 1.2.0-notls/modules/usrloc//udomain.c:404
> #1 0xffffffff7d9131c4 in child_init (_rank=1344858528) at
> /home/operador/openser-1.2.0-notls/modules/usrloc//ul_mod.c:344
> #2 0x0000000100082500 in init_mod_child (m=0x1, rank=1,
> type=0x1000f41b0 "CHILD") at
> /home/operador/openser-1.2.0-notls//sr_module.c:400
> #3 0x0000000100082460 in init_mod_child (m=0x1, rank=1,
> type=0x1000f41b0 "CHILD") at
> /home/operador/openser-1.2.0-notls//sr_module.c:394
> #4 0x0000000100082460 in init_mod_child (m=0x1, rank=1,
> type=0x1000f41b0 "CHILD") at
> /home/operador/openser-1.2.0-notls //sr_module.c:394
> #5 0x0000000100082770 in init_child (rank=1) at
> /home/operador/openser-1.2.0-notls//sr_module.c:394
> #6 0x0000000100032414 in main_loop () at
> /home/operador/openser- 1.2.0-notls//main.c:724
> #7 0x00000001000345a4 in main (argc=2, argv=0xffffff7e7007a000)
> at /home/operador/openser-1.2.0-notls//main.c:1399
>
>
>
>
> On 3/26/07, *Daniel-Constantin Mierla* < daniel@voice-system.ro
> <mailto:daniel@voice-system.ro>> wrote:
>
> Hello,
>
> can you send a gdb backtrace :-D -- I cannot read adb backtrace.
>
> Cheers,
> Daniel
>
>
> On 03/26/07 19:42, Sergio Gutierrez wrote:
> > Hi Daniel.
> >
> > This is the backtrace, obtained with adb:
> >
> > usrloc.so`preload_udomain+0x4cc(1, ffffffff7228e9f0, 100215a00,
> > ffffffff7d919e58, ffffffffffefe3f8, 0)
> > 0xffffffff7d9131bc(2, ffffffff7da1c9b0, ffffffff7d91a170,
> > ffffffff7228e9a0, ffffffff7da1b0a8, ffffffffffeff0c8)
> > init_mod_child+0xd8(100269930, 1, 1000f41b0, 1000f40f0, 1,
> 100269870)
> > init_mod_child+0x38(100269bb0, 1, 1000f41b0, 1000f40f0, 1,
> 1002699f0)
> > init_mod_child+0x38(100269d30, 1, 1000f41b0, 1000f40f0, 1,
> 100269c70)
> > init_child+0xa8(1, 100269df0, 1, 1000f4168, 10020d000, 100269eb0)
> > main_loop+0xf34(0, 8c, 1000eefd8, ffffffff720083c4, 1002694b0, 0)
> > main+0x1e10(100215, 9, 0, 10020d000, 1000ef5b8, 10020d000)
> > _start+0x7c(0, 0, 0, 0, 0, 0)
> >
> > On 3/26/07, *Sergio Gutierrez* <saguti@gmail.com
> <mailto:saguti@gmail.com>
> > <mailto: saguti@gmail.com <mailto:saguti@gmail.com>>> wrote:
> >
> > Hi Daniel.
> >
> > I used 512 for -m parameter.
> >
> > Would you like the backtrace of the core file?
> >
> > Thanks.
> >
> >
> > On 3/26/07, *Daniel-Constantin Mierla* <
> daniel@voice-system.ro <mailto:daniel@voice-system.ro>
> > <mailto: daniel@voice-system.ro
> <mailto:daniel@voice-system.ro>>> wrote:
> >
> > Hello,
> >
> > could you send a backtrace? What was the value for
> parameter -m?
> >
> > Cheers,
> > Daniel
> >
> >
> > On 03/26/07 19:29, Sergio Gutierrez wrote:
> > > Hi
> > >
> > > I am trying to run Openser compiled on 64 bits on a
> SPARC
> > Machine
> > > running Solaris 10.
> > >
> > > When I create a simple configuration file for
> testing radius
> > > integration, Openser starts to consume the whole
> memory
> > reservation
> > > (-m parameter) and fails with segmentation fault error.
> > >
> > > after several tests, I have found that the error is
> caused by
> > save()
> > > function (registrar module).
> > >
> > > This is the main route my configuration file:
> > >
> > > route {
> > > if(method=="REGISTER")
> > > {
> > > if(!radius_www_authorize(""))
> > > {
> > > www_challenge("", "0");
> > > return;
> > > };
> > >
> > > if(!save("location"))
> > > {
> > > sl_reply_error();
> > > };
> > > return;
> > >
> > > }
> > > else
> > > {
> > > }
> > > }
> > >
> > > Thanks in advance for your help.
> > >
> > > Sergio G.
> > >
> > >
> ------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > Users mailing list
> > > Users@openser.org <mailto:Users@openser.org>
> <mailto: Users@openser.org <mailto: Users@openser.org>>
> > > http://openser.org/cgi-bin/mailman/listinfo/users
> <http://openser.org/cgi-bin/mailman/listinfo/users >
> > >
> >
> >
> >
>
>
>