29 Mar
2007
29 Mar
'07
8:24 p.m.
You are correct, the crash is happening in the SNMPStats module. I'll
take a look!
- JM
Daniel-Constantin Mierla wrote:
Hello,
this seems to be in snmpstats module ... maybe the developer can give
some hints.
Cheers,
Daniel
On 03/29/07 19:29, Sergio Gutierrez wrote:
Hi Daniel.
In the meantime, I have begun to test using more standard conditions;
I am not using the optimized compiler and I am running openser
compiled on 32 bits.
I have discovered an even nastier issue. When Openser is configured
in forking mode, and with or without log_stderror, it presents the
same symptom I reported when compiled on 64 bits (it exhausts the
shared memory reservation, and crashes with core dumping).
This is the backtrace:
(gdb) bt
#0 0x00000000 in ?? ()
#1 0xfe989b3c in getRow (ipType=1, ipAddress=0x141888) at
openserSIPPortTable.c:125
#2 0xfe989c5c in createRowsFromIPList (theList=0x141a50, listSize=1,
protocol=0, snmpIndex=0xffbff870) at openserSIPPortTable.c:201
#3 0xfe98a07c in init_openserSIPPortTable () at
openserSIPPortTable.c:241
#4 0xfe98d708 in spawn_agentx_child () at sub_agent.c:74
#5 0xfe98cf04 in mod_child_init (rank=0) at snmpstats.c:271
#6 0x00059ca8 in init_mod_child (m=0x133840, rank=0, type=0xc3c08
"PROC_MAIN") at sr_module.c:406
#7 0x00059c24 in init_mod_child (m=0x1338e0, rank=0, type=0xc3c08
"PROC_MAIN") at sr_module.c:395
#8 0x000336c4 in main_loop () at main.c:952
#9 0x00035be4 in main (argc=9, argv=0xe7800) at main.c:1399
When I configure fork=no, openser does not crash, and works right.
I apologize if I should better create a new thread. If you suggest so
I will do it.
Thanks in advance for your attention.
Kind regards
Sergio Gutierrez.
EPM Telecomunicaciones
Medellín, Colombia
Tel: 574 - 3950022
<mailto: daniel(a)voice-system.ro
<mailto:daniel@voice-system.ro>>
------------------------------------------------------------------------
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users ---------- Forwarded message ----------
From: *Sergio Gutierrez* <saguti(a)gmail.com
<mailto:saguti@gmail.com> <mailto: saguti(a)gmail.com
<mailto:saguti@gmail.com>>>
Date: Mar 27, 2007 9:52 AM
Subject: Re: [Users] Openser fails when compiled on Solaris
64bit
To: daniel(a)voice-system.ro
<mailto:daniel@voice-system.ro>
<mailto: daniel(a)voice-system.ro
<mailto:daniel@voice-system.ro>>
Cc: users(a)openser.org
<mailto:users@openser.org>
<mailto:users@openser.org
<mailto:users@openser.org>>
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.
On 3/27/07, *Daniel-Constantin Mierla* <
daniel(a)voice-system.ro
<mailto:daniel@voice-system.ro>
<mailto:daniel@voice-system.ro
<mailto:daniel@voice-system.ro>>> wrote:
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(a)gmail.com
<mailto:saguti@gmail.com>
<mailto:saguti@gmail.com
<mailto:saguti@gmail.com>>
> <mailto: saguti(a)gmail.com <mailto:saguti@gmail.com>
<mailto: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(a)voice-system.ro
<mailto:daniel@voice-system.ro> > <mailto: daniel(a)voice-system.ro
<mailto:daniel@voice-system.ro>
<mailto: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(a)gmail.com
<mailto:saguti@gmail.com>
<mailto: saguti(a)gmail.com
<mailto:saguti@gmail.com>>
> <mailto: saguti(a)gmail.com
<mailto:saguti@gmail.com> <mailto: saguti(a)gmail.com
<mailto:saguti@gmail.com>>>
> > <mailto:
saguti(a)gmail.com
<mailto:saguti@gmail.com> <mailto:
saguti(a)gmail.com
<mailto:saguti@gmail.com>>
<mailto:saguti@gmail.com
<mailto:saguti@gmail.com>
<mailto: saguti(a)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(a)voice-system.ro
<mailto:daniel@voice-system.ro> <mailto:
daniel(a)voice-system.ro <mailto:daniel@voice-system.ro>>
<mailto: daniel(a)voice-system.ro
<mailto:daniel@voice-system.ro> <mailto:daniel@voice-system.ro
<mailto:daniel@voice-system.ro>>>
> > <mailto:
daniel(a)voice-system.ro
<mailto:daniel@voice-system.ro>
<mailto: daniel(a)voice-system.ro
<mailto:daniel@voice-system.ro>>
> <mailto:
daniel(a)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(a)openser.org
<mailto:Users@openser.org> <mailto: Users(a)openser.org
<mailto:Users@openser.org>>
<mailto: Users(a)openser.org
<mailto:Users@openser.org>
<mailto: Users(a)openser.org
<mailto:Users@openser.org>>>
> <mailto: Users(a)openser.org
<mailto:Users@openser.org> <mailto: Users(a)openser.org
<mailto:Users@openser.org>>
<mailto: Users(a)openser.org
<mailto:Users@openser.org>
<mailto: Users(a)openser.org
<mailto:Users@openser.org>>>>
> > >
http://openser.org/cgi-bin/mailman/listinfo/users
> <
http://openser.org/cgi-bin/mailman/listinfo/users
<http://openser.org/cgi-bin/mailman/listinfo/users>
> <http://openser.org/cgi-bin/mailman/listinfo/users>>
> > >
> > >
> > >
> > >
> >
> >
> >
>
>