29 Mar
2007
29 Mar
'07
7:54 p.m.
Thanks Daniel.
It is worth to say that the previously reported issue, when openser is
compiled on 64bits, occurs when it is started either on 32 or 64 bits.
Kind regards.
On 3/29/07, Daniel-Constantin Mierla <daniel(a)voice-system.ro> 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:
(_c=0x10026ad90,
(_c=0x10026ad90,
<mailto: daniel(a)voice-system.ro
<mailto:daniel@voice-system.ro>>
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
64bit
---------- 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 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 >
_d=0xffffffff5028e9f0) at udomain.c:404
> 404 if
(VAL_NULL(ROW_VALUES(row))
> > (gdb) bt
> > #0 0xffffffff7d90e2a0 in preload_udomain >
_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.
> > >
> > >