[OpenSIPS-Users] b2bua core dump & db truncate

[thrillerbee]

I'm waiting for my b2bua box to core dump again so I can get the backtrace,
but is it expected behavior that OpenSIPS cannot restart w/o first
truncating the b2b_entities & b2b_logic tables?  That makes for a messy
recovery...

Thanks.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] b2bua core dump & db truncate

[Anca Vamanu]

Hi,

At startup, the b2b_tables are copied into memory and are truncated, 
then the data is updated in the database at an interval controlled by 
the update_period parameter ( by default 100 seconds).

As for the core dump, if you are using trunk, can you please update your 
code? I just committed a lot of changes in those modules.

Regards,

-- 
Anca Vamanu
www.voice-system.ro




On 10/26/2010 06:58 AM, thrillerbee wrote:
> I'm waiting for my b2bua box to core dump again so I can get the 
> backtrace, but is it expected behavior that OpenSIPS cannot restart 
> w/o first truncating the b2b_entities & b2b_logic tables?  That makes 
> for a messy recovery...
>
> Thanks.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] b2bua core dump & db truncate

[thrillerbee]

Anca,

Thanks for the info.  I'll let you know if I have issues after the upgrade.

Thanks.

On Tue, Oct 26, 2010 at 3:42 AM, Anca Vamanu  wrote:

> Hi,
>
> At startup, the b2b_tables are copied into memory and are truncated,
> then the data is updated in the database at an interval controlled by
> the update_period parameter ( by default 100 seconds).
>
> As for the core dump, if you are using trunk, can you please update your
> code? I just committed a lot of changes in those modules.
>
> Regards,
>
> --
> Anca Vamanu
> www.voice-system.ro
>
>
>
>
> On 10/26/2010 06:58 AM, thrillerbee wrote:
> > I'm waiting for my b2bua box to core dump again so I can get the
> > backtrace, but is it expected behavior that OpenSIPS cannot restart
> > w/o first truncating the b2b_entities & b2b_logic tables?  That makes
> > for a messy recovery...
> >
> > Thanks.
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] b2bua core dump & db truncate

[thrillerbee]

Anca,

I am still seeing core dumps.  bt attached.

Thanks.

On Tue, Oct 26, 2010 at 8:44 AM, thrillerbee  wrote:

> Anca,
>
> Thanks for the info.  I'll let you know if I have issues after the upgrade.
>
> Thanks.
>
>
> On Tue, Oct 26, 2010 at 3:42 AM, Anca Vamanu  wrote:
>
>> Hi,
>>
>> At startup, the b2b_tables are copied into memory and are truncated,
>> then the data is updated in the database at an interval controlled by
>> the update_period parameter ( by default 100 seconds).
>>
>> As for the core dump, if you are using trunk, can you please update your
>> code? I just committed a lot of changes in those modules.
>>
>> Regards,
>>
>> --
>> Anca Vamanu
>> www.voice-system.ro
>>
>>
>>
>>
>> On 10/26/2010 06:58 AM, thrillerbee wrote:
>> > I'm waiting for my b2bua box to core dump again so I can get the
>> > backtrace, but is it expected behavior that OpenSIPS cannot restart
>> > w/o first truncating the b2b_entities & b2b_logic tables?  That makes
>> > for a messy recovery...
>> >
>> > Thanks.
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
Core was generated by `/usr/local/sbin/opensips -P 
/var/run/opensips/opensips.pid -m 2048 -u root -g r'.
Program terminated with signal 11, Segmentation fault.
[New process 10170]
#0  0x7f77f488e343 in t_uac (method=0x7f77f3676c90, headers=0x0, body=0x0, 
dialog=0x7a5890, cb=0, cbp=0x0, release_func=0) at uac.c:287
287 LM_DBG("building sip_msg from buffer\n");
(gdb) bt full
#0  0x7f77f488e343 in t_uac (method=0x7f77f3676c90, headers=0x0, body=0x0, 
dialog=0x7a5890, cb=0, cbp=0x0, release_func=0) at uac.c:287
to_su = {s = {sa_family = 2, sa_data = 
"\023##XB\n\000\000\000\000\000\000\000"}, sin = {sin_family = 2, sin_port = 
50195, sin_addr = {s_addr = 172120272}, 
sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 2, 
sin6_port = 50195, sin6_flowinfo = 172120272, sin6_addr = {in6_u = {u6_addr8 = 
'\0' , 
u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, u6_addr32 = {0, 0, 0, 0}}}, 
sin6_scope_id = 0}}
new_cell = (struct cell *) 0x7f7773b6a250
backup = 
buf = 0x0
buf1 = 
buf_len = 
buf_len1 = 
ret = 
flags = 
backup_route_type = 
hi = 
send_sock = 
req = (struct sip_msg *) 0x0
__FUNCTION__ = "t_uac"
#1  0x7f77f3468dc5 in b2b_tm_cback (t=, htable=0xc8, 
ps=0x7a5418) at dlg.c:1724
hash_index = 32767
local_index = 4246031144
b2b_cback = (b2b_notify_t) 0x7a5418 
dlg = (b2b_dlg_t *) 0x38
param = {s = 0x79a178 "", len = 7971888}
statuscode = 32631
leg = 
pto = 
TO = {error = 56, body = {s = 0x744548 "###rw\177", len = 7970440}, uri 
= {s = 0x7f77f34702c1 , len = 0}, display 
= {s = 0x793fe0 "\002", 
len = 2}, tag_value = {s = 0x0, len = 7970440}, parsed_uri = {user = {s = 
0x7f7772ede400 "", len = 1940377152}, passwd = {s = 0x7f77f39e87b9 " ", len = 
1949299264}, host = {
  s = 0xc800794030 , len = 4}, port = 
{s = 0x0, len = 7970440}, params = {s = 0x479dfb "##11##", len = 2}, 
headers = {s = 0x794080 "\001", 
  len = 3}, port_no = 0, proto = 0, type = ERROR_URI_T, transport = {s = 
0x799e88 "\205`", len = 4693460}, ttl = {s = 0x2 , 
len = 7926528}, user_param = {
  s = 0x7944a8 "\017", len = 14}, maddr = {s = 0xfffb , len = 7970440}, method = {s = 0x12 , len = 7741483}, lr = {
  s = 0x3b , len = 5032233}, r2 = {s = 0x799e88 
"\205`", len = 7926528}, transport_val = {
  s = 0x76202b 
"tion/sdp,application/isup,application/dtmf,application/dtmf-relay,multipart/mixed\r\nRequire:
 timer\r\nSupported: timer\r\nAllow: 
INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTI"...,
 len = 7741600}, ttl_val = {s = 0x1 , len = 
7994120}, user_param_val = {
  s = 0xdfd154db0 , len = 0}, maddr_val 
= {s = 0x0, len = 7994176}, method_val = {
  s = 0x76203f 
"/isup,application/dtmf,application/dtmf-relay,multipart/mixed\r\nRequire: 
timer\r\nSupported: timer\r\nAllow: 
INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH\r"...,
 len = 7741600}, lr_val = {s = 0x3 , len = 4957221}, 
r2_val = {s = 0x0, len = 7918344}}, param_lst = 0x7a3558, 
  last_param = 0x78d308}
to_tag = {
  s = 0x761fcd "4-4cc6f5be-af15dbeb-5967ee57\r\nCall-ID: 
B2B.1847.1171930\r\nCSeq: 3717657 INVITE\r\nAccept: 
application/sdp,application/isup,application/dtmf,application/dtmf-relay,multipart/mixed\r\nRequire:
 timer\r\nSupport"..., len = 7741405}
callid = {s = 0x79a168 "", len = 7994120}
from_tag = {s = 0x3b , len = 5032233}
require_hdr = 
method_id = 0
__FUNCTION__ = "b2b_tm_cback"
#2  0x7f77f3463988 in b2b_prescript_f (msg=0x7d154d80, uparam=) at dlg.c:601
b2b_key = {
  s = 0x762030 
"sdp,applica

Re: [OpenSIPS-Users] b2bua core dump & db truncate

[Anca Vamanu]

Hi,

The lines in your gdb backtrace don't match at all. Have you altered the 
code or is the core corrupted?


Regards,

--
Anca Vamanu
www.voice-system.ro



On 11/01/2010 04:35 PM, thrillerbee wrote:

Anca,

I am still seeing core dumps.  bt attached.

Thanks.

On Tue, Oct 26, 2010 at 8:44 AM, thrillerbee > wrote:


Anca,

Thanks for the info.  I'll let you know if I have issues after the
upgrade.

Thanks.


On Tue, Oct 26, 2010 at 3:42 AM, Anca Vamanu mailto:a...@opensips.org>> wrote:

Hi,

At startup, the b2b_tables are copied into memory and are
truncated,
then the data is updated in the database at an interval
controlled by
the update_period parameter ( by default 100 seconds).

As for the core dump, if you are using trunk, can you please
update your
code? I just committed a lot of changes in those modules.

Regards,

--
Anca Vamanu
www.voice-system.ro 




On 10/26/2010 06:58 AM, thrillerbee wrote:
> I'm waiting for my b2bua box to core dump again so I can get the
> backtrace, but is it expected behavior that OpenSIPS cannot
restart
> w/o first truncating the b2b_entities & b2b_logic tables?
 That makes
> for a messy recovery...
>
> Thanks.

___
Users mailing list
Users@lists.opensips.org 
http://lists.opensips.org/cgi-bin/mailman/listinfo/users




___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
   
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] b2bua core dump & db truncate

[thrillerbee]

Anca,

I had not altered the code.  It core dumped pretty quickly so I was force to
revert to revision 7317.
I will try to schedule some time to retest the newest revision and see if it
core dumps again.

Thanks again.

On Mon, Nov 1, 2010 at 10:44 AM, Anca Vamanu  wrote:

>  Hi,
>
> The lines in your gdb backtrace don't match at all. Have you altered the
> code or is the core corrupted?
>
>
> Regards,
>
> --
> Anca Vamanuwww.voice-system.ro
>
>
>
> On 11/01/2010 04:35 PM, thrillerbee wrote:
>
> Anca,
>
>  I am still seeing core dumps.  bt attached.
>
>  Thanks .
>
> On Tue, Oct 26, 2010 at 8:44 AM, thrillerbee wrote:
>
>> Anca,
>>
>>  Thanks for the info.  I'll let you know if I have issues after the
>> upgrade.
>>
>>  Thanks.
>>
>>
>> On Tue, Oct 26, 2010 at 3:42 AM, Anca Vamanu  wrote:
>>
>>> Hi,
>>>
>>> At startup, the b2b_tables are copied into memory and are truncated,
>>> then the data is updated in the database at an interval controlled by
>>> the update_period parameter ( by default 100 seconds).
>>>
>>> As for the core dump, if you are using trunk, can you please update your
>>> code? I just committed a lot of changes in those modules.
>>>
>>> Regards,
>>>
>>> --
>>> Anca Vamanu
>>> www.voice-system.ro
>>>
>>>
>>>
>>>
>>> On 10/26/2010 06:58 AM, thrillerbee wrote:
>>> > I'm waiting for my b2bua box to core dump again so I can get the
>>> > backtrace, but is it expected behavior that OpenSIPS cannot restart
>>> > w/o first truncating the b2b_entities & b2b_logic tables?  That makes
>>> > for a messy recovery...
>>> >
>>> > Thanks.
>>>
>>>  ___
>>> Users mailing list
>>> Users@lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>
>>
>
> ___
> Users mailing 
> listus...@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] b2bua core dump & db truncate

[thrillerbee]

Anca,

I am seeing a crash about every 13-14 days.  I've attached the backtrace
from this morning.
The other problem is that OpenSIPS immediately crashes when monit tries to
restart it. I have to manually truncate the b2b_entities & b2b_logic tables
to get it to start w/o crashing.  I'm attaching this backtrace as well
(called *restart*).

Thanks.

On Mon, Nov 1, 2010 at 10:56 AM, thrillerbee  wrote:

> Anca,
>
> I had not altered the code.  It core dumped pretty quickly so I was force
> to revert to revision 7317.
> I will try to schedule some time to retest the newest revision and see if
> it core dumps again.
>
> Thanks again.
>
> On Mon, Nov 1, 2010 at 10:44 AM, Anca Vamanu  wrote:
>
>>  Hi,
>>
>> The lines in your gdb backtrace don't match at all. Have you altered the
>> code or is the core corrupted?
>>
>>
>> Regards,
>>
>> --
>> Anca Vamanuwww.voice-system.ro
>>
>>
>>
>> On 11/01/2010 04:35 PM, thrillerbee wrote:
>>
>> Anca,
>>
>>  I am still seeing core dumps.  bt attached.
>>
>>  Thanks .
>>
>> On Tue, Oct 26, 2010 at 8:44 AM, thrillerbee wrote:
>>
>>> Anca,
>>>
>>>  Thanks for the info.  I'll let you know if I have issues after the
>>> upgrade.
>>>
>>>  Thanks.
>>>
>>>
>>> On Tue, Oct 26, 2010 at 3:42 AM, Anca Vamanu  wrote:
>>>
 Hi,

 At startup, the b2b_tables are copied into memory and are truncated,
 then the data is updated in the database at an interval controlled by
 the update_period parameter ( by default 100 seconds).

 As for the core dump, if you are using trunk, can you please update your
 code? I just committed a lot of changes in those modules.

 Regards,

 --
 Anca Vamanu
 www.voice-system.ro




 On 10/26/2010 06:58 AM, thrillerbee wrote:
 > I'm waiting for my b2bua box to core dump again so I can get the
 > backtrace, but is it expected behavior that OpenSIPS cannot restart
 > w/o first truncating the b2b_entities & b2b_logic tables?  That makes
 > for a messy recovery...
 >
 > Thanks.

  ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users

>>>
>>>
>>
>> ___
>> Users mailing 
>> listus...@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
Core was generated by `/usr/local/sbin/opensips -P 
/var/run/opensips/opensips.pid -m 2048 -u root -g r'.
Program terminated with signal 11, Segmentation fault.
[New process 12409]
#0  t_unref_cell (c=0x0) at t_lookup.c:1169
1169UNREF(c);
(gdb) bt full
#0  t_unref_cell (c=0x0) at t_lookup.c:1169
__FUNCTION__ = "t_unref_cell"
#1  0x7fe9774ec9e1 in b2b_prescript_f (msg=0x799e88, uparam=) at dlg.c:488
reason = {s = 0x7fe9774f58c0 "OK", len = 2}
b2b_key = {s = 0x799e88 "s len = 1}
dlg = 
hash_index = 
local_index = 
b2b_cback = 
param = {s = 0x0, len = 0}
table = 
method_value = 
TO = {error = 7741452, body = {s = 0xa , len 
= 0}, uri = {s = 0x7fe90006 "", len = 0}, display = {
s = 0x762066 "38794...@68.68.124.33>;tag=gK0b7076d4\r\nTo: 
;tag=B2B.2482.3343\r\nCall-ID: 
772517652_72287...@68.68.124.33\r\ncseq: 12225 PRACK\r\nMax-Forwards: 
68\r\nRAck: 113 12224 INVITE\r\nConte"..., len = 70}, tag_value = {s = 
0x56b00497f81 , len = 0}, parsed_uri = 
{user = {
  s = 0x761fac "121.80.39;branch=z9hG4bKaeec.ed9119a4.0\r\nVia: SIP/2.0/UDP 
24.121.80.36;branch=z9hG4bKaeec.5a7bedb.0\r\nVia: SIP/2.0/UDP 
68.68.124.33:5060;branch=z9hG4bK0bB84d6261f073b06b6\r\nFrom: 
;t"..., len = 98}, host = {s = 0x4d5ba9 
"H\211D$XH\205##\017#T$0D\213\\$(\017\204###", len = 59}, port = {
  s = 0x4cc929 "h\21...@h\205##\213t$\030l\213\\$\020\017\204###", len = 
7741335}, params = {s = 0x7fffc7331f78 "###", len = 7741337}, headers = {s = 
0x0, 
  len = 1963685894}, port_no = 27160, proto = 124, type = ERROR_URI_T, 
transport = {s = 0x76213e "", len = 7741341}, ttl = {
  s = 0x761fb6 "branch=z9hG4bKaeec.ed9119a4.0\r\nVia: SIP/2.0/UDP 
24.121.80.36;branch=z9hG4bKaeec.5a7bedb.0\r\nVia: SIP/2.0/UDP 
68.68.124.33:5060;branch=z9hG4bK0bB84d6261f073b06b6\r\nFrom: 
;t"..., len = 8005424}, user_param = {
  s = 0x761fc1 "4bKaeec.ed9119a4.0\r\nVia: SIP/2.0/UDP 
24.121.80.36;branch=z9hG4bKaeec.5a7bedb.0\r\nVia: SIP/2.0/UDP 
68.68.124.33:5060;branch=z9hG4bK0bB84d6261f073b06b6\r\nFrom: 
;tag=gK0b7076"..., len = 7741724}, maddr = {s = 
0x3 , len = 4957221}, method = {s = 0x799e88 "s 
len = 510}, 
lr = {s = 0x7cb518 "\001", len = 7741341}, r2 = {s = 0x7c6a18 "\001", len = 
7741758}, transport_val = {
  s = 0x761f9d "SIP/2.0/UDP 
24.121.80.39;branch=z9hG4bKaeec.ed9119a4.0\r\nVia: SIP/2.0/UDP

Re: [OpenSIPS-Users] b2bua core dump & db truncate

[Anca Vamanu]

Hi,

I have found the cause of the crash and fixed it. Please update your code.

Thanks and regards,

--
Anca Vamanu
www.voice-system.ro



On 11/09/2010 06:40 PM, thrillerbee wrote:

Anca,

I am seeing a crash about every 13-14 days.  I've attached the 
backtrace from this morning.
The other problem is that OpenSIPS immediately crashes when monit 
tries to restart it. I have to manually truncate the b2b_entities & 
b2b_logic tables to get it to start w/o crashing.  I'm attaching this 
backtrace as well (called /restart/).


Thanks.

On Mon, Nov 1, 2010 at 10:56 AM, thrillerbee > wrote:


Anca,

I had not altered the code.  It core dumped pretty quickly so I
was force to revert to revision 7317.
I will try to schedule some time to retest the newest revision and
see if it core dumps again.

Thanks again.

On Mon, Nov 1, 2010 at 10:44 AM, Anca Vamanu mailto:a...@opensips.org>> wrote:

Hi,

The lines in your gdb backtrace don't match at all. Have you
altered the code or is the core corrupted?


Regards,

-- 
Anca Vamanu

www.voice-system.ro  



On 11/01/2010 04:35 PM, thrillerbee wrote:

Anca,

I am still seeing core dumps.  bt attached.

Thanks .

On Tue, Oct 26, 2010 at 8:44 AM, thrillerbee
mailto:thriller...@gmail.com>> wrote:

Anca,

Thanks for the info.  I'll let you know if I have issues
after the upgrade.

Thanks.


On Tue, Oct 26, 2010 at 3:42 AM, Anca Vamanu
mailto:a...@opensips.org>> wrote:

Hi,

At startup, the b2b_tables are copied into memory and
are truncated,
then the data is updated in the database at an
interval controlled by
the update_period parameter ( by default 100 seconds).

As for the core dump, if you are using trunk, can you
please update your
code? I just committed a lot of changes in those modules.

Regards,

--
Anca Vamanu
www.voice-system.ro 




On 10/26/2010 06:58 AM, thrillerbee wrote:
> I'm waiting for my b2bua box to core dump again so
I can get the
> backtrace, but is it expected behavior that
OpenSIPS cannot restart
> w/o first truncating the b2b_entities & b2b_logic
tables?  That makes
> for a messy recovery...
>
> Thanks.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] b2bua core dump & db truncate

[thrillerbee]

Anca,

The b2b_logic module will not compile:

make[1]: Entering directory `/usr/local/src/opensips_1_6/modules/b2b_logic'
Compiling b2b_logic.c
gcc -fPIC -DPIC -g -O9 -funroll-loops -Wcast-align -Wall
-minline-all-stringops -falign-loops -ftree-vectorize -mtune=prescott
-Wold-style-definition -Wmissing-field-initializers -Wredundant-decls
-DMOD_NAME='"b2b_logic"'-DNAME='"opensips"' -DVERSION='"1.6.3-notls"'
-DARCH='"i386"' -DOS='"linux"' -DCOMPILER='"gcc 4.3.2"' -D__CPU_i386
-D__OS_linux -D__SMP_yes -DCFG_DIR='"/usr/local/etc/opensips/"' -DPKG_MALLOC
-DSHM_MEM  -DSHM_MMAP -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE
-DHAVE_RESOLV_RES -DSTATISTICS -DCHANGEABLE_DEBUG_LEVEL -DF_MALLOC
 -DSVNREVISION='"2:7361"'  -DFAST_LOCK -DADAPTIVE_WAIT
-DADAPTIVE_WAIT_LOOPS=1024  -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN
-DHAVE_SCHED_YIELD -DHAVE_MSG_NOSIGNAL -DHAVE_MSGHDR_MSG_CONTROL
-DHAVE_ALLOCA_H -DHAVE_TIMEGM -DHAVE_EPOLL -DHAVE_SIGIO_RT -DHAVE_SELECT
-I/usr/include/libxml2 -I/usr/local/include/libxml2 -I/usr/local/include -c
b2b_logic.c -o b2b_logic.o
Compiling logic.c
gcc -fPIC -DPIC -g -O9 -funroll-loops -Wcast-align -Wall
-minline-all-stringops -falign-loops -ftree-vectorize -mtune=prescott
-Wold-style-definition -Wmissing-field-initializers -Wredundant-decls
-DMOD_NAME='"b2b_logic"'-DNAME='"opensips"' -DVERSION='"1.6.3-notls"'
-DARCH='"i386"' -DOS='"linux"' -DCOMPILER='"gcc 4.3.2"' -D__CPU_i386
-D__OS_linux -D__SMP_yes -DCFG_DIR='"/usr/local/etc/opensips/"' -DPKG_MALLOC
-DSHM_MEM  -DSHM_MMAP -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE
-DHAVE_RESOLV_RES -DSTATISTICS -DCHANGEABLE_DEBUG_LEVEL -DF_MALLOC
 -DSVNREVISION='"2:7361"'  -DFAST_LOCK -DADAPTIVE_WAIT
-DADAPTIVE_WAIT_LOOPS=1024  -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN
-DHAVE_SCHED_YIELD -DHAVE_MSG_NOSIGNAL -DHAVE_MSGHDR_MSG_CONTROL
-DHAVE_ALLOCA_H -DHAVE_TIMEGM -DHAVE_EPOLL -DHAVE_SIGIO_RT -DHAVE_SELECT
-I/usr/include/libxml2 -I/usr/local/include/libxml2 -I/usr/local/include -c
logic.c -o logic.o
logic.c: In function ‘process_bridge_bye’:
logic.c:352: warning: passing argument 4 of ‘b2b_api.send_reply’ makes
integer from pointer without a cast
logic.c:352: warning: passing argument 7 of ‘b2b_api.send_reply’ from
incompatible pointer type
logic.c:352: error: too few arguments to function ‘b2b_api.send_reply’
logic.c: In function ‘b2b_logic_notify’:
logic.c:780: warning: passing argument 4 of ‘b2b_api.send_reply’ makes
integer from pointer without a cast
logic.c:780: warning: passing argument 7 of ‘b2b_api.send_reply’ from
incompatible pointer type
logic.c:780: error: too few arguments to function ‘b2b_api.send_reply’
logic.c:848: warning: passing argument 4 of ‘b2b_api.send_reply’ makes
integer from pointer without a cast
logic.c:848: warning: passing argument 7 of ‘b2b_api.send_reply’ from
incompatible pointer type
logic.c:848: error: too few arguments to function ‘b2b_api.send_reply’
logic.c:851: warning: passing argument 4 of ‘b2b_api.send_reply’ makes
integer from pointer without a cast
logic.c:851: warning: passing argument 7 of ‘b2b_api.send_reply’ from
incompatible pointer type
logic.c:851: error: too few arguments to function ‘b2b_api.send_reply’
logic.c:857: warning: passing argument 4 of ‘b2b_api.send_reply’ makes
integer from pointer without a cast
logic.c:857: warning: passing argument 7 of ‘b2b_api.send_reply’ from
incompatible pointer type
logic.c:857: error: too few arguments to function ‘b2b_api.send_reply’
logic.c:1052: warning: passing argument 4 of ‘b2b_api.send_reply’ makes
integer from pointer without a cast
logic.c:1052: warning: passing argument 7 of ‘b2b_api.send_reply’ from
incompatible pointer type
logic.c:1052: error: too few arguments to function ‘b2b_api.send_reply’
make[1]: *** [logic.o] Error 1
make[1]: Leaving directory `/usr/local/src/opensips_1_6/modules/b2b_logic'
make: *** [modules] Error 2

Regards.

On Wed, Nov 10, 2010 at 6:10 AM, Anca Vamanu  wrote:

>  Hi,
>
> I have found the cause of the crash and fixed it. Please update your code.
>
> Thanks and regards,
>
>
> --
> Anca Vamanuwww.voice-system.ro
>
>
>
> On 11/09/2010 06:40 PM, thrillerbee wrote:
>
> Anca,
>
>  I am seeing a crash about every 13-14 days.  I've attached the backtrace
> from this morning.
> The other problem is that OpenSIPS immediately crashes when monit tries to
> restart it. I have to manually truncate the b2b_entities & b2b_logic tables
> to get it to start w/o crashing.  I'm attaching this backtrace as well
> (called *restart*).
>
>  Thanks.
>
> On Mon, Nov 1, 2010 at 10:56 AM, thrillerbee wrote:
>
>> Anca,
>>
>> I had not altered the code.  It core dumped pretty quickly so I was force
>> to revert to revision 7317.
>> I will try to schedule some time to retest the newest revision and see if
>> it core dumps again.
>>
>> Thanks again.
>>
>> On Mon, Nov 1, 2010 at 10:44 AM, Anca Vamanu  wrote:
>>
>>>  Hi,
>>>
>>> The lines in your gdb backtrace don't match at all. Have you altered the
>>> code or is the core corrupted?
>>>
>>>
>>> R

Re: [OpenSIPS-Users] b2bua core dump & db truncate

[Anca Vamanu]

Hi,

You were right, sorry, I did a partial commit. It is now ok.

Regards,
Anca


--
Anca Vamanu
www.voice-system.ro


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] b2bua core dump & db truncate

[thrillerbee]

New core dump on rev 7371
Backtrace attached.

Thanks.

On Thu, Nov 11, 2010 at 4:41 AM, Anca Vamanu  wrote:

> Hi,
>
> You were right, sorry, I did a partial commit. It is now ok.
>
> Regards,
> Anca
>
>
>
> --
> Anca Vamanu
> www.voice-system.ro
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
Core was generated by `/usr/local/sbin/opensips -P 
/var/run/opensips/opensips.pid -m 2048 -u root -g r'.
Program terminated with signal 11, Segmentation fault.
[New process 8731]
#0  0xb712f8e5 in b2b_search_htable (table=0x0, hash_index=155, 
local_index=3481) at dlg.c:141
141 dlg= table[hash_index].first;
(gdb) bt full
#0  0xb712f8e5 in b2b_search_htable (table=0x0, hash_index=155, 
local_index=3481) at dlg.c:141
dlg = 
__FUNCTION__ = "b2b_search_htable"
#1  0xb71235db in b2b_restore_logic_info (type=B2B_SERVER, key=0xbf89bf80, 
cback=0xb728cf3c ) at b2b_entities.c:357
dlg = 
table = (b2b_table) 0x0
hash_index = 155
local_index = 3481
__FUNCTION__ = "b2b_restore_logic_info"
#2  0xb7280a0c in b2b_logic_restore () at b2b_logic.c:1213
i = 0
nr_rows = 12
result = (db_res_t *) 0x819df68
rows = (db_row_t *) 0x81a4310
row_vals = 
tuple = {id = 0, key = 0xbf89c0b0, scenario = 0x0, scenario_params = 
{{s = 0x99b80ad "", len = 0}, {s = 0x99b80ae "", len = 0}, {
  s = 0x99b80af "", len = 0}, {s = 0x99b80b0 "", len = 0}, {s = 0x99b80b1 
"", len = 0}}, scenario_state = -3, next_scenario_state = 0, 
  server = 0x0, clients = 0x0, bridge_entities = {0xbf89bf78, 0xbf89bfb0, 
0xbf89bfe8}, to_del = 0, extra_headers = 0x0, next = 0x0, prev = 0x0, 
  insert_time = 0, lifetime = 0, sdp = {s = 0x99b80b2 "", len = 0}, db_flag = 0}
b2bl_key = {s = 0x99b80a0 "1789.0", len = 6}
scenario_id = {s = 0x99b80a7 "", len = 0}
bridge_entities = {{scenario_id = {s = 0x99b80b5 "", len = 0}, key = {s 
= 0x99b80f6 "B2B.155.3481", len = 12}, to_uri = {
  s = 0x99b80b6 "sip:244517062375...@66.234.136.133", len = 34}, from_uri = 
{s = 0x99b80d9 "sip:9375592...@207.2.123.187", len = 28}, 
dlginfo = 0x0, disconnected = 0, state = 0, type = B2B_SERVER, next = 0x0, 
peer = 0x0}, {scenario_id = {s = 0x99b8105 "", len = 0}, key = {
  s = 0x99b8146 "B2B.1789.7511494", len = 16}, to_uri = {s = 0x99b8106 
"sip:244517062375...@66.234.136.133", len = 34}, from_uri = {
  s = 0x99b8129 "sip:9375592...@207.2.123.187", len = 28}, dlginfo = 0x0, 
disconnected = 0, state = 0, type = B2B_CLIENT, next = 0x0, 
peer = 0x0}, {scenario_id = {s = 0x99b8157 "", len = 0}, key = {s = 
0x99b815a "", len = 0}, to_uri = {s = 0x99b8158 "", len = 0}, 
from_uri = {s = 0x99b8159 "", len = 0}, dlginfo = 0x0, disconnected = 0, 
state = 0, type = 3076297573, next = 0x0, peer = 0x0}}
params = {0xbf89c02c, 0xbf89c034, 0xbf89c03c, 0xbf89c044, 0xbf89c04c}
result_cols = {0xb7294340, 0xb7294348, 0xb7294380, 0xb7294388, 
0xb7294350, 0xb7294358, 0xb7294360, 0xb7294368, 0xb7294370, 0xb7294378, 
  0xb7294390, 0xb7294398, 0xb72943a0, 0xb72943a8, 0xb72943b0, 0xb72943b8, 
0xb72943c0, 0xb72943c8, 0xb72943d0, 0xb72943d8, 0xb72943e0, 
  0xb72943e8, 0xb72943f0, 0xb72943f8, 0xb7294400}
__FUNCTION__ = "b2b_logic_restore"
---Type  to continue, or q  to quit---
#3  0xb7281aff in mod_init () at b2b_logic.c:252
p = 
i = 
j = 
__FUNCTION__ = "mod_init"
#4  0x080b781c in init_mod (m=0x819ee38) at sr_module.c:457
__FUNCTION__ = "init_mod"
#5  0x080b77b8 in init_mod (m=0x819eee0) at sr_module.c:452
__FUNCTION__ = "init_mod"
#6  0x0806e1cb in main (argc=9, argv=0xbf89c2a4) at main.c:1351
cfg_log_stderr = 0
cfg_stream = (FILE *) 0x9998008
c = 
r = 
tmp = 0xbf89cea4 ""
tmp_len = 
port = 
proto = 
ret = 
seed = 2146665141
rfd = 
__FUNCTION__ = "main"
(gdb) ___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] b2bua core dump & db truncate

[Anca Vamanu]

Hi,

Have you by any chance loaded the b2b_logic module before b2b_entities 
module?


Regards,
Anca

On 11/14/2010 12:18 AM, thrillerbee wrote:

New core dump on rev 7371
Backtrace attached.

Thanks.

On Thu, Nov 11, 2010 at 4:41 AM, Anca Vamanu > wrote:


Hi,

You were right, sorry, I did a partial commit. It is now ok.

Regards,
Anca



-- 
Anca Vamanu

www.voice-system.ro 


___
Users mailing list
Users@lists.opensips.org 
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
   



--
Anca Vamanu
www.voice-system.ro

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] b2bua core dump & db truncate

[thrillerbee]

Actually, yes, I have.  Is that incorrect?  I'll reverse the order they're
loaded & test.

Thanks.

On Mon, Nov 15, 2010 at 11:37 AM, Anca Vamanu  wrote:

>  Hi,
>
> Have you by any chance loaded the b2b_logic module before b2b_entities
> module?
>
> Regards,
> Anca
>
>
> On 11/14/2010 12:18 AM, thrillerbee wrote:
>
> New core dump on rev 7371
> Backtrace attached.
>
>  Thanks.
>
> On Thu, Nov 11, 2010 at 4:41 AM, Anca Vamanu  wrote:
>
>> Hi,
>>
>> You were right, sorry, I did a partial commit. It is now ok.
>>
>> Regards,
>> Anca
>>
>>
>>
>> --
>> Anca Vamanu
>> www.voice-system.ro
>>
>>
>>  ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
> ___
> Users mailing 
> listus...@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> --
> Anca Vamanuwww.voice-system.ro
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] b2bua core dump & db truncate

[Anca Vamanu]

They must be loaded in reverse order because b2b_logic depends on 
b2b_entities  - but it shouldn't crash, I will fix that.


Thanks also.

On 11/15/2010 07:41 PM, thrillerbee wrote:
Actually, yes, I have.  Is that incorrect?  I'll reverse the order 
they're loaded & test.


Thanks.

On Mon, Nov 15, 2010 at 11:37 AM, Anca Vamanu > wrote:


Hi,

Have you by any chance loaded the b2b_logic module before
b2b_entities module?

Regards,
Anca


On 11/14/2010 12:18 AM, thrillerbee wrote:

New core dump on rev 7371
Backtrace attached.

Thanks.

On Thu, Nov 11, 2010 at 4:41 AM, Anca Vamanu mailto:a...@opensips.org>> wrote:

Hi,

You were right, sorry, I did a partial commit. It is now ok.

Regards,
Anca



-- 
Anca Vamanu

www.voice-system.ro 


___
Users mailing list
Users@lists.opensips.org 
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



___
Users mailing list
Users@lists.opensips.org  
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
   



-- 
Anca Vamanu

www.voice-system.ro  
 



___
Users mailing list
Users@lists.opensips.org 
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
   



--
Anca Vamanu
www.voice-system.ro

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] b2bua core dump & db truncate

[thrillerbee]

Anca,

I upgraded to rev 7383 and changed config to:

...
loadmodule "b2b_entities.so"
loadmodule "b2b_logic.so"
...

It crashed after about 15 minutes of moderate traffic.  It actually wrote 2
core files so I've attached both backtraces (first is *_e.txt, second is
*_2.txt).

Thanks again.

On Mon, Nov 15, 2010 at 11:44 AM, Anca Vamanu  wrote:

>  They must be loaded in reverse order because b2b_logic depends on
> b2b_entities  - but it shouldn't crash, I will fix that.
>
> Thanks also.
>
>
> On 11/15/2010 07:41 PM, thrillerbee wrote:
>
> Actually, yes, I have.  Is that incorrect?  I'll reverse the order they're
> loaded & test.
>
>  Thanks.
>
> On Mon, Nov 15, 2010 at 11:37 AM, Anca Vamanu  wrote:
>
>>  Hi,
>>
>> Have you by any chance loaded the b2b_logic module before b2b_entities
>> module?
>>
>> Regards,
>> Anca
>>
>>
>> On 11/14/2010 12:18 AM, thrillerbee wrote:
>>
>> New core dump on rev 7371
>> Backtrace attached.
>>
>>  Thanks.
>>
>> On Thu, Nov 11, 2010 at 4:41 AM, Anca Vamanu  wrote:
>>
>>> Hi,
>>>
>>> You were right, sorry, I did a partial commit. It is now ok.
>>>
>>> Regards,
>>> Anca
>>>
>>>
>>>
>>> --
>>> Anca Vamanu
>>> www.voice-system.ro
>>>
>>>
>>>  ___
>>> Users mailing list
>>> Users@lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>
>>
>> ___
>> Users mailing 
>> listus...@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>> --
>> Anca Vamanuwww.voice-system.ro
>>
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
> ___
> Users mailing 
> listus...@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> --
> Anca Vamanuwww.voice-system.ro
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
Core was generated by `/usr/local/sbin/opensips -P 
/var/run/opensips/opensips.pid -m 2048 -u root -g r'.
Program terminated with signal 11, Segmentation fault.
[New process 23158]
#0  0xb72f5a1c in t_uac (method=0xb7277498, headers=0x0, body=0x0, 
dialog=0x81a5b90, cb=0, cbp=0x0, release_func=0) at ../../mem/../hash_func.h:56
56  v=(*p<<24)+(p[1]<<16)+(p[2]<<8)+p[3];
(gdb) bt
#0  0xb72f5a1c in t_uac (method=0xb7277498, headers=0x0, body=0x0, 
dialog=0x81a5b90, cb=0, cbp=0x0, release_func=0) at ../../mem/../hash_func.h:56
#1  0xb72f72c3 in req_within (method=0xb7277498, headers=0x0, body=0x0, 
dialog=0x81a5b90, completion_cb=0, cbp=0x0, release_func=0) at uac.c:396
#2  0xb726a340 in b2b_send_req (dlg=0x3985d8dc, leg=0x81a576c, 
method=0xb7277498, extra_headers=0x0) at dlg.c:1701
#3  0xb72713b6 in b2b_tm_cback (t=0x3c4db4f0, htable=0x37276efc, ps=0xb73018d4) 
at dlg.c:1983
#4  0xb7264fd2 in b2b_client_tm_cback (t=0x3c4db4f0, type=512, ps=0xb73018d4) 
at client.c:44
#5  0xb72dc924 in run_trans_callbacks (type=512, trans=0x3c4db4f0, req=0x0, 
rpl=0x81a5088, code=200) at t_hooks.c:208
#6  0xb72f36f6 in local_reply (t=0x3c4db4f0, p_msg=0x81a5088, branch=0, 
msg_status=200, cancel_bitmap=0xbfc09c80) at t_reply.c:1348
#7  0xb72f4a39 in reply_received (p_msg=0x81a5088) at t_reply.c:1493
#8  0x080678c2 in forward_reply (msg=0x81a5088) at forward.c:559
#9  0x080986bb in receive_msg (
buf=0x81783a0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 
207.36.90.52;branch=z9hG4bK7bad.deb109c1.0\r\nContact: 
\r\nTo: 
;tag=58dcb4ae-co6123-INS001\r\nFrom: , u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 
0}, u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id = 0}}
new_cell = (struct cell *) 0x3d2473a0
backup = 
buf = 
buf1 = 
buf_len = 
buf_len1 = 
ret = 
flags = 
backup_route_type = 
hi = 
send_sock = 
req = (struct sip_msg *) 0x0
__FUNCTION__ = "t_uac"
#1  0xb72f72c3 in req_within (method=0xb7277498, headers=0x0, body=0x0, 
dialog=0x81a5b90, completion_cb=0, cbp=0x0, release_func=0) at uac.c:396
__FUNCTION__ = "req_within"
#2  0xb726a340 in b2b_send_req (dlg=0x3985d8dc, leg=0x81a576c, 
method=0xb7277498, extra_headers=0x0) at dlg.c:1701
td = (dlg_t *) 0x0
result = 
__FUNCTION__ = "b2b_send_req"
#3  0xb72713b6 in b2b_tm_cback (t=0x3c4db4f0, htable=0x37276efc, ps=0xb73018d4) 
at dlg.c:1983
hash_index = 3090
local_index = 3665002
b2b_cback = (b2b_notify_t) 0xb7255efb 
dlg = (b2b_dlg_t *) 0x3985d8dc
param = {s = 0x81b21ac "3090.8", len = 6}
statuscode = 200
leg = (dlg_leg_t *) 0x81a576c
pto = 
TO = {error = 135933872, body = {s = 0x81a5088 "/\034", len = 0}, uri = 
{s = 0xb72bb73d "\205##017\210\234\002", len = -1077896652}, display = {
s = 0x81a5524 "D\204\027\b\026

Re: [OpenSIPS-Users] b2bua core dump & db truncate

[thrillerbee]

Anca,

Did you receive these backtraces?

Thanks.

On Mon, Nov 15, 2010 at 1:20 PM, thrillerbee  wrote:

> Anca,
>
> I upgraded to rev 7383 and changed config to:
>
> ...
> loadmodule "b2b_entities.so"
> loadmodule "b2b_logic.so"
> ...
>
> It crashed after about 15 minutes of moderate traffic.  It actually wrote 2
> core files so I've attached both backtraces (first is *_e.txt, second is
> *_2.txt).
>
> Thanks again.
>
> On Mon, Nov 15, 2010 at 11:44 AM, Anca Vamanu  wrote:
>
>>  They must be loaded in reverse order because b2b_logic depends on
>> b2b_entities  - but it shouldn't crash, I will fix that.
>>
>> Thanks also.
>>
>>
>> On 11/15/2010 07:41 PM, thrillerbee wrote:
>>
>> Actually, yes, I have.  Is that incorrect?  I'll reverse the order they're
>> loaded & test.
>>
>>  Thanks.
>>
>> On Mon, Nov 15, 2010 at 11:37 AM, Anca Vamanu  wrote:
>>
>>>  Hi,
>>>
>>> Have you by any chance loaded the b2b_logic module before b2b_entities
>>> module?
>>>
>>> Regards,
>>> Anca
>>>
>>>
>>> On 11/14/2010 12:18 AM, thrillerbee wrote:
>>>
>>> New core dump on rev 7371
>>> Backtrace attached.
>>>
>>>  Thanks.
>>>
>>> On Thu, Nov 11, 2010 at 4:41 AM, Anca Vamanu  wrote:
>>>
 Hi,

 You were right, sorry, I did a partial commit. It is now ok.

 Regards,
 Anca



 --
 Anca Vamanu
 www.voice-system.ro


  ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users

>>>
>>>
>>> ___
>>> Users mailing 
>>> listus...@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>>
>>> --
>>> Anca Vamanuwww.voice-system.ro
>>>
>>>
>>> ___
>>> Users mailing list
>>> Users@lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>> ___
>> Users mailing 
>> listus...@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>> --
>> Anca Vamanuwww.voice-system.ro
>>
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] b2bua core dump & db truncate

[Anca Vamanu]

Hi,

Can you please update - I have fixed on Friday a similar crash.

Regards,
Anca

On 19/11/10 16:43, thrillerbee wrote:

Anca,

Did you receive these backtraces?

Thanks.

On Mon, Nov 15, 2010 at 1:20 PM, thrillerbee > wrote:


Anca,

I upgraded to rev 7383 and changed config to:

...
loadmodule "b2b_entities.so"
loadmodule "b2b_logic.so"
...

It crashed after about 15 minutes of moderate traffic.  It
actually wrote 2 core files so I've attached both
backtraces (first is *_e.txt, second is *_2.txt).

Thanks again.

On Mon, Nov 15, 2010 at 11:44 AM, Anca Vamanu mailto:a...@opensips.org>> wrote:

They must be loaded in reverse order because b2b_logic depends
on b2b_entities  - but it shouldn't crash, I will fix that.

Thanks also.


On 11/15/2010 07:41 PM, thrillerbee wrote:

Actually, yes, I have.  Is that incorrect?  I'll reverse the
order they're loaded & test.

Thanks.

On Mon, Nov 15, 2010 at 11:37 AM, Anca Vamanu
mailto:a...@opensips.org>> wrote:

Hi,

Have you by any chance loaded the b2b_logic module before
b2b_entities module?

Regards,
Anca


On 11/14/2010 12:18 AM, thrillerbee wrote:

New core dump on rev 7371
Backtrace attached.

Thanks.

On Thu, Nov 11, 2010 at 4:41 AM, Anca Vamanu
mailto:a...@opensips.org>> wrote:

Hi,

You were right, sorry, I did a partial commit. It is
now ok.

Regards,
Anca



-- 
Anca Vamanu

www.voice-system.ro 


___
Users mailing list
Users@lists.opensips.org

http://lists.opensips.org/cgi-bin/mailman/listinfo/users



___
Users mailing list
Users@lists.opensips.org  
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
   



-- 
Anca Vamanu

www.voice-system.ro  
 



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] b2bua core dump & db truncate

[thrillerbee]

Anca,

I am still seeing core dumps on rev 7441 - it was up for about 5 min.
 Backtrace attached.

Thanks.

On Sat, Nov 20, 2010 at 7:56 AM, Anca Vamanu  wrote:

>  Hi,
>
> Can you please update - I have fixed on Friday a similar crash.
>
> Regards,
> Anca
>
>
> On 19/11/10 16:43, thrillerbee wrote:
>
> Anca,
>
>  Did you receive these backtraces?
>
>  Thanks.
>
> On Mon, Nov 15, 2010 at 1:20 PM, thrillerbee wrote:
>
>> Anca,
>>
>>  I upgraded to rev 7383 and changed config to:
>>
>>  ...
>>  loadmodule "b2b_entities.so"
>> loadmodule "b2b_logic.so"
>> ...
>>
>>  It crashed after about 15 minutes of moderate traffic.  It actually
>> wrote 2 core files so I've attached both backtraces (first is *_e.txt,
>> second is *_2.txt).
>>
>>  Thanks again.
>>
>> On Mon, Nov 15, 2010 at 11:44 AM, Anca Vamanu  wrote:
>>
>>> They must be loaded in reverse order because b2b_logic depends on
>>> b2b_entities  - but it shouldn't crash, I will fix that.
>>>
>>> Thanks also.
>>>
>>>
>>> On 11/15/2010 07:41 PM, thrillerbee wrote:
>>>
>>> Actually, yes, I have.  Is that incorrect?  I'll reverse the order
>>> they're loaded & test.
>>>
>>>  Thanks.
>>>
>>> On Mon, Nov 15, 2010 at 11:37 AM, Anca Vamanu  wrote:
>>>
 Hi,

 Have you by any chance loaded the b2b_logic module before b2b_entities
 module?

 Regards,
 Anca


 On 11/14/2010 12:18 AM, thrillerbee wrote:

 New core dump on rev 7371
 Backtrace attached.

  Thanks.

 On Thu, Nov 11, 2010 at 4:41 AM, Anca Vamanu  wrote:

> Hi,
>
> You were right, sorry, I did a partial commit. It is now ok.
>
> Regards,
> Anca
>
>
>
> --
> Anca Vamanu
> www.voice-system.ro
>
>
>  ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


 ___
 Users mailing 
 listus...@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users



 --
 Anca Vamanuwww.voice-system.ro


>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
(gdb) bt
#0  0xb7304a1c in t_uac (method=0xb7286498, headers=0x0, body=0x0, 
dialog=0x81a85d0, cb=0, cbp=0x0, release_func=0) at ../../mem/../hash_func.h:56
#1  0xb73062c3 in req_within (method=0xb7286498, headers=0x0, body=0x0, 
dialog=0x81a85d0, completion_cb=0, cbp=0x0, release_func=0) at uac.c:396
#2  0xb7279340 in b2b_send_req (dlg=0x38dfc8f0, leg=0x81a850c, 
method=0xb7286498, extra_headers=0x0) at dlg.c:1701
#3  0xb72803b6 in b2b_tm_cback (t=0x38d4db80, htable=0x37285f28, ps=0xb73108d4) 
at dlg.c:1983
#4  0xb7273fd2 in b2b_client_tm_cback (t=0x38d4db80, type=512, ps=0xb73108d4) 
at client.c:44
#5  0xb72eb924 in run_trans_callbacks (type=512, trans=0x38d4db80, req=0x0, 
rpl=0x81a5088, code=200) at t_hooks.c:208
#6  0xb73026f6 in local_reply (t=0x38d4db80, p_msg=0x81a5088, branch=0, 
msg_status=200, cancel_bitmap=0xbfd1a6e0) at t_reply.c:1350
#7  0xb7303a39 in reply_received (p_msg=0x81a5088) at t_reply.c:1495
#8  0x080678c2 in forward_reply (msg=0x81a5088) at forward.c:559
#9  0x080986bb in receive_msg (
buf=0x81783a0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 
217.36.90.52;branch=z9hG4bKa672.4df87e96.0\r\nFrom: 
;tag=6d0a496ae253b92ea43eeacbb0d408bd\r\nTo: 
sip:15055369...@67.228.15.154;tag=1cc81d203d"..., 
len=681, rcv_info=0xbfd1a804) at receive.c:200
#10 0x080d9ba4 in udp_rcv_loop () at udp_server.c:492
#11 0x0806ea79 in main (argc=9, argv=0xbfd1a9a4) at main.c:818
(gdb) bt full
#0  0xb7304a1c in t_uac (method=0xb7286498, headers=0x0, body=0x0, 
dialog=0x81a85d0, cb=0, cbp=0x0, release_func=0) at ../../mem/../hash_func.h:56
to_su = {s = {sa_family = 2, sa_data = 
"\023#17\232\000\000\000\000\000\000\000"}, sin = {sin_family = 2, sin_port 
= 50195, sin_addr = {s_addr = 2584732739}, sin_zero = 
"\000\000\000\000\000\000\000"}, sin6 = {
sin6_family = 2, sin6_port = 50195, sin6_flowinfo = 2584732739, sin6_addr = 
{in6_u = {u6_addr8 = '\0' , u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 
0}, u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id = 0}}
new_cell = (struct cell *) 0x38612d50
backup = 
buf = 
buf1 = 
buf_len = 
buf_len1 = 
ret = 
flags = 
backup_route_type = 
hi = 
send_sock = 
req = (struct sip_msg *) 0x0
__FUNCTION__ = "t_uac"
#1  0xb73062c3 in req_within (method=0xb7286498, headers=0x0, body=0x0, 
dialog=0x81a85d0, completion_cb=0, cbp=0x0, release_func=0) at uac.c:396
__FUNCTION__ = "req_within"
#2  0xb7279340 in b2b_send_req (dlg=0x38dfc8f0, leg=0x81a850c, 
method=0xb7286498, extra_headers=0x0) at dlg.c:1701
td = (dlg_t *) 0x0
result = 
__FUNCTION__ = "b2b_send_req"
#3  0