subject:"\[SR\-Users\] possible bug with dialog module"

Re: [SR-Users] possible bug with dialog module

2010-04-23 Thread Daniel-Constantin Mierla


Hello,

thanks, so the Contact header is missing, that makes the 200ok invalid 
for invitate - afaik contact is mandatory. Anyhow, crash should not 
happen, but I wonder what happens with such call, practically the caller 
does not know where to send the BYE. Or maybe 18x reply has contact hdr 
and that is used ...


Cheers,
Daniel

On 4/22/10 12:00 PM, Kelvin Chua wrote:


(gdb) print buf+300
$2 = 0x869fec "65\r\nCall-ID: 
0901b21e13a60e0247988caf7d72f...@10.17.0.200 
\r\nCSeq: 102 
INVITE\r\nServer: Cisco ATA 186  v3.2.0 atasip (04A)\r\nAllow: 
ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER, PRACK, U"...


(gdb) print buf+400
$1 = 0x86a050 "v3.2.0 atasip (04A)\r\nAllow: ACK, BYE, CANCEL, 
INVITE, NOTIFY, OPTIONS, REFER, REGISTER, PRACK, UPDATE\r\nSupported: 
replaces\r\nContent-Length: 0\r\n\r\n"


(gdb) print buf+500
$4 = 0x86a0b4 "PDATE\r\nSupported: replaces\r\nContent-Length: 0\r\n\r\n"

(gdb) print buf+600
$5 = 0x86a118 "ip:3...@10.17.0.200 
>\r\nContent-Length: 0\r\n\r\n"


(gdb) print buf+700
$6 = 0x86a17c "A/8000\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:97 
iLBC/8000\r\na=fmtp:97 mode=30\r\na=rtpmap:3 GSM/8000\r\na=rtpmap:101 
telephone-event/8000\r\na=fmtp:101 0-16\r\na=silenceSupp:off - - - 
-\r\na=ptime:20\r\na=sendrecv\r\n"


(gdb) print buf+800
$7 = 0x86a1e0 "p:101 telephone-event/8000\r\na=fmtp:101 
0-16\r\na=silenceSupp:off - - - -\r\na=ptime:20\r\na=sendrecv\r\n"


(gdb) print buf+900
$8 = 0x86a244 "8000\r\na=fmtp:101 0-16,32-36,54\r\na=silenceSupp:off - 
- - -\r\n"


(gdb) print buf+1000
$9 = 0x86a2a8 "0\r\na=fmtp:101 0-15\r\n"

(gdb) print buf+1100
$10 = 0x86a30c "000\r\na=ptime:20\r\na=rtpmap:8 
PCMA/8000\r\na=rtpmap:4 G723/8000\r\na=rtpmap:18 
G729/8000\r\na=rtpmap:2 G726-32/8000\r\na=rtpmap:97 
iLBC/8000\r\na=fmtp:97 mode=20\r\na=rtpmap:102 
G729E/8000\r\na=rtpmap:100 AAL2-G726-1"...


(gdb) print buf+1200
$11 = 0x86a370 "32/8000\r\na=rtpmap:97 iLBC/8000\r\na=fmtp:97 
mode=20\r\na=rtpmap:102 G729E/8000\r\na=rtpmap:100 
AAL2-G726-16/8000\r\na=rtpmap:101 telephone-event/8000\r\na=fmtp:101 
0-16,32-36,54\r\n"


(gdb) print buf+1300
$12 = 0x86a3d4 "6/8000\r\na=rtpmap:101 
telephone-event/8000\r\na=fmtp:101 0-16,32-36,54\r\n"


(gdb) print buf+1400
$13 = 0x86a438 ""

(gdb) print buf+1500
$14 = 0x86a49c "5395257\"\r\nContent-Length: 0\r\n\r\n"


Kelvin Chua


On Thu, Apr 22, 2010 at 4:49 PM, Daniel-Constantin Mierla 
mailto:mico...@gmail.com>> wrote:


Hi,

if you still have the core file, can you print more of buffer
until it gets to end of headers? I am curios to see what is wrong
with the contact.

Just increase by 100:

(gdb) print buf+300
(gdb) print buf+400
...

Thanks,
Daniel


On 4/21/10 3:15 PM, Kelvin Chua wrote:

(gdb) bt
#0  0x2ab61b62779a in update_dialog_dbinfo
(cell=0x2ab61c9100f8) at dlg_db_handler.c:501
#1  0x2ab61b628ea8 in dlg_onreply (t=0x7d5228, type=, param=) at dlg_handlers.c:361
#2  0x2ab617965505 in run_trans_callbacks_internal
(cb_lst=0x2ab61c938830, type=128, trans=0x2ab61c9387c0,
params=0x7fffec157970) at t_hooks.c:261
#3  0x2ab61796575e in run_trans_callbacks (type=1,
trans=0x88c580, req=0x0, rpl=0x0, code=477060464) at t_hooks.c:288
#4  0x2ab61798ebd1 in relay_reply (t=0x2ab61c9387c0,
p_msg=, branch=0, msg_status=200,
cancel_bitmap=0x7fffec157dd4, do_put_on_wait=1) at t_reply.c:1705
#5  0x2ab617990884 in reply_received (p_msg=0x8f48a8) at
t_reply.c:2126
#6  0x0044760e in forward_reply (msg=0x8f48a8) at
forward.c:689
#7  0x0047fd22 in receive_msg (
buf=0x869ec0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP
10.17.0.202;branch=z9hG4bK75b5.e2a38a16.0\r\nVia: SIP/2.0/UDP
10.17.0.200:5060;branch=z9hG4bK730bcb55;rport=5060\r\nRecord-Route:
\r"..., len=,
rcv_info=0x7fffec158020) at receive.c:257
#8  0x00505e2b in udp_rcv_loop () at udp_server.c:520
#9  0x00455adf in main_loop () at main.c:1447
#10 0x00456be2 in main (argc=,
argv=0x7fffec1582e8) at main.c:2251



(gdb) print cell
$1 = (struct dlg_cell *) 0x2ab61c9100f8



(gdb) print *cell
$2 = {ref = 2, next = 0x0, prev = 0x0, h_id = 996587990, h_entry
= 1420, state = 3, lifetime = 3600, start_ts = 1271816397,
  dflags = 1, sflags = 0, toroute = 0, from_rr_nb = 0, tl = {next
= 0x0, prev = 0x0, timeout = 0}, callid = {
s = 0x2ab61c910238

"0901b21e13a60e0247988caf7d72f...@10.17.0.200sip:029147...@10.17.0.200sip:4...@hiddendomain.edusip:4...@10.17.40.77:5060;user=phone;transport=udpent-Length:
0\r\n\r\n"

,
len = 44}, from_uri = {
s = 0x2ab61c910264

"sip:029147...@10.

Re: [SR-Users] possible bug with dialog module

2010-04-23 Thread Daniel-Constantin Mierla


Hello,

thanks, so the Contact header is missing, that makes the 200ok invalid 
for invitate - afaik contact is mandatory. Anyhow, crash should not 
happen, but I wonder what happens with such call, practically the caller 
does not know where to send the BYE. Or maybe 18x reply has contact hdr 
and that is used ...


Cheers,
Daniel

On 4/22/10 12:00 PM, Kelvin Chua wrote:


(gdb) print buf+300
$2 = 0x869fec "65\r\nCall-ID: 
0901b21e13a60e0247988caf7d72f...@10.17.0.200 
\r\nCSeq: 102 
INVITE\r\nServer: Cisco ATA 186  v3.2.0 atasip (04A)\r\nAllow: 
ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER, PRACK, U"...


(gdb) print buf+400
$1 = 0x86a050 "v3.2.0 atasip (04A)\r\nAllow: ACK, BYE, CANCEL, 
INVITE, NOTIFY, OPTIONS, REFER, REGISTER, PRACK, UPDATE\r\nSupported: 
replaces\r\nContent-Length: 0\r\n\r\n"


(gdb) print buf+500
$4 = 0x86a0b4 "PDATE\r\nSupported: replaces\r\nContent-Length: 0\r\n\r\n"

(gdb) print buf+600
$5 = 0x86a118 "ip:3...@10.17.0.200 
>\r\nContent-Length: 0\r\n\r\n"


(gdb) print buf+700
$6 = 0x86a17c "A/8000\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:97 
iLBC/8000\r\na=fmtp:97 mode=30\r\na=rtpmap:3 GSM/8000\r\na=rtpmap:101 
telephone-event/8000\r\na=fmtp:101 0-16\r\na=silenceSupp:off - - - 
-\r\na=ptime:20\r\na=sendrecv\r\n"


(gdb) print buf+800
$7 = 0x86a1e0 "p:101 telephone-event/8000\r\na=fmtp:101 
0-16\r\na=silenceSupp:off - - - -\r\na=ptime:20\r\na=sendrecv\r\n"


(gdb) print buf+900
$8 = 0x86a244 "8000\r\na=fmtp:101 0-16,32-36,54\r\na=silenceSupp:off - 
- - -\r\n"


(gdb) print buf+1000
$9 = 0x86a2a8 "0\r\na=fmtp:101 0-15\r\n"

(gdb) print buf+1100
$10 = 0x86a30c "000\r\na=ptime:20\r\na=rtpmap:8 
PCMA/8000\r\na=rtpmap:4 G723/8000\r\na=rtpmap:18 
G729/8000\r\na=rtpmap:2 G726-32/8000\r\na=rtpmap:97 
iLBC/8000\r\na=fmtp:97 mode=20\r\na=rtpmap:102 
G729E/8000\r\na=rtpmap:100 AAL2-G726-1"...


(gdb) print buf+1200
$11 = 0x86a370 "32/8000\r\na=rtpmap:97 iLBC/8000\r\na=fmtp:97 
mode=20\r\na=rtpmap:102 G729E/8000\r\na=rtpmap:100 
AAL2-G726-16/8000\r\na=rtpmap:101 telephone-event/8000\r\na=fmtp:101 
0-16,32-36,54\r\n"


(gdb) print buf+1300
$12 = 0x86a3d4 "6/8000\r\na=rtpmap:101 
telephone-event/8000\r\na=fmtp:101 0-16,32-36,54\r\n"


(gdb) print buf+1400
$13 = 0x86a438 ""

(gdb) print buf+1500
$14 = 0x86a49c "5395257\"\r\nContent-Length: 0\r\n\r\n"


Kelvin Chua


On Thu, Apr 22, 2010 at 4:49 PM, Daniel-Constantin Mierla 
mailto:mico...@gmail.com>> wrote:


Hi,

if you still have the core file, can you print more of buffer
until it gets to end of headers? I am curios to see what is wrong
with the contact.

Just increase by 100:

(gdb) print buf+300
(gdb) print buf+400
...

Thanks,
Daniel


On 4/21/10 3:15 PM, Kelvin Chua wrote:

(gdb) bt
#0  0x2ab61b62779a in update_dialog_dbinfo
(cell=0x2ab61c9100f8) at dlg_db_handler.c:501
#1  0x2ab61b628ea8 in dlg_onreply (t=0x7d5228, type=, param=) at dlg_handlers.c:361
#2  0x2ab617965505 in run_trans_callbacks_internal
(cb_lst=0x2ab61c938830, type=128, trans=0x2ab61c9387c0,
params=0x7fffec157970) at t_hooks.c:261
#3  0x2ab61796575e in run_trans_callbacks (type=1,
trans=0x88c580, req=0x0, rpl=0x0, code=477060464) at t_hooks.c:288
#4  0x2ab61798ebd1 in relay_reply (t=0x2ab61c9387c0,
p_msg=, branch=0, msg_status=200,
cancel_bitmap=0x7fffec157dd4, do_put_on_wait=1) at t_reply.c:1705
#5  0x2ab617990884 in reply_received (p_msg=0x8f48a8) at
t_reply.c:2126
#6  0x0044760e in forward_reply (msg=0x8f48a8) at
forward.c:689
#7  0x0047fd22 in receive_msg (
buf=0x869ec0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP
10.17.0.202;branch=z9hG4bK75b5.e2a38a16.0\r\nVia: SIP/2.0/UDP
10.17.0.200:5060;branch=z9hG4bK730bcb55;rport=5060\r\nRecord-Route:
\r"..., len=,
rcv_info=0x7fffec158020) at receive.c:257
#8  0x00505e2b in udp_rcv_loop () at udp_server.c:520
#9  0x00455adf in main_loop () at main.c:1447
#10 0x00456be2 in main (argc=,
argv=0x7fffec1582e8) at main.c:2251



(gdb) print cell
$1 = (struct dlg_cell *) 0x2ab61c9100f8



(gdb) print *cell
$2 = {ref = 2, next = 0x0, prev = 0x0, h_id = 996587990, h_entry
= 1420, state = 3, lifetime = 3600, start_ts = 1271816397,
  dflags = 1, sflags = 0, toroute = 0, from_rr_nb = 0, tl = {next
= 0x0, prev = 0x0, timeout = 0}, callid = {
s = 0x2ab61c910238

"0901b21e13a60e0247988caf7d72f...@10.17.0.200sip:029147...@10.17.0.200sip:4...@hiddendomain.edusip:4...@10.17.40.77:5060;user=phone;transport=udpent-Length:
0\r\n\r\n"

,
len = 44}, from_uri = {
s = 0x2ab61c910264

"sip:029147...@10.

Re: [SR-Users] possible bug with dialog module

2010-04-22 Thread Kelvin Chua

these Cisco ATAs are so old, we are maintaining around 300 of these, and a
lot of times
we encounter corrupted SIP messages of which some are fixed by just reboots,
other times,
by upgrading firmwares.

most of the times, kamailio manages to stay afloat in the midst
of all these corruption except for some instances like the one i'm
reporting, it didn't.

i am currently getting the latest git and will test.
the last crash we encountered before yesterday is march 30 and before that,
january 5.
if i manage to upgrade this now, we won't know if it really works not unless
we monitor this
for at least 3 months :-)

Kelvin Chua


On Thu, Apr 22, 2010 at 4:47 PM, Daniel-Constantin Mierla  wrote:

> Hi Timo,
>
> thanks for troubleshooting. I committed the patch that moves setting of
> bind_addr before any error case in populate_leg_info(). I backported to
> kamailio_3.0 branch as well.
>
> Kelvin, can you get the lasted git version for branch kamailio_3.0 and
> test?
>
> Thanks,
> Daniel
>
>
> On 4/22/10 1:21 AM, Timo Reimann wrote:
>
>> Hello,
>>
>>
>> Kelvin Chua wrote:
>>
>>
>>> (gdb) bt
>>> #0  0x2ab61b62779a in update_dialog_dbinfo (cell=0x2ab61c9100f8) at
>>> dlg_db_handler.c:501
>>>
>>>
>> This corresponds to
>>
>>   SET_STR_VALUE(values+8, cell->bind_addr[DLG_CALLEE_LEG]->sock_str);
>>
>> so assumingly sip-router crashes when it tries to access the callee's
>> bound address's sock_str...
>>
>>
>>
>>
>>> #1  0x2ab61b628ea8 in dlg_onreply (t=0x7d5228, type=>> out>, param=) at dlg_handlers.c:361
>>> #2  0x2ab617965505 in run_trans_callbacks_internal
>>> (cb_lst=0x2ab61c938830, type=128, trans=0x2ab61c9387c0,
>>>
>>> (gdb) print cell
>>> $1 = (struct dlg_cell *) 0x2ab61c9100f8
>>>
>>>
>>>
>>> (gdb) print *cell
>>> 0}}, bind_addr = {0x88c580, 0x0},
>>>   cbs = {first = 0x0, types = 0}, profile_links = 0x0}
>>>
>>>
>> ... as supported by the fact that bind_addr's second field
>> (DLG_CALLEE_LEG) is 0.
>>
>> Why does the segfault happen?
>>
>> Let's trace the code path: The initial error message
>>
>> "bad sip message or missing Contact hdr"
>>
>> occurred in dlg_handlers.c, line 218, which makes this piece of code's
>> surrounding function "populate_leg_info" return prematurely (by means of
>> "goto error0"). Specifically, this implies that the code at the end of
>> the function on line 272
>>
>>   dlg->bind_addr[leg] = msg->rcv.bind_address;
>>
>> isn't carried out anymore, leaving the callee's bound address associated
>> with the given dialog unassigned. (This happens to be the only occasion
>> where the bound address is assigned.) Instead, execution drops back to
>> the "dlg_onreply" function and proceeds to line 361, thereby calling the
>> database update function:
>>
>>   update_dialog_dbinfo(dlg);
>>
>> which directly leads to the segfaulting code location.
>>
>>
>> AFAICS, "update_dialog_dbinfo" is dereferencing a possibly null memory
>> location at the dialog data in question only, so one way to prevent the
>> segfault from happening is to move the bound address assignment before
>> any failing code in the function. This should make sure that some
>> accessible bound address is stored in any case.
>>
>>
>> Cheers,
>>
>> --Timo
>>
>>
>
> --
> Daniel-Constantin Mierla * http://www.asipto.com/ *
> http://twitter.com/miconda *
> http://www.linkedin.com/in/danielconstantinmierla
>
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] possible bug with dialog module

2010-04-22 Thread Kelvin Chua

(gdb) print buf+300
$2 = 0x869fec "65\r\nCall-ID:
0901b21e13a60e0247988caf7d72f...@10.17.0.200\r\ncseq:
102 INVITE\r\nServer: Cisco ATA 186  v3.2.0 atasip (04A)\r\nAllow: ACK,
BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER, PRACK, U"...

(gdb) print buf+400
$1 = 0x86a050 "v3.2.0 atasip (04A)\r\nAllow: ACK, BYE, CANCEL, INVITE,
NOTIFY, OPTIONS, REFER, REGISTER, PRACK, UPDATE\r\nSupported:
replaces\r\nContent-Length: 0\r\n\r\n"

(gdb) print buf+500
$4 = 0x86a0b4 "PDATE\r\nSupported: replaces\r\nContent-Length: 0\r\n\r\n"

(gdb) print buf+600
$5 = 0x86a118 "ip:3...@10.17.0.200 >\r\nContent-Length:
0\r\n\r\n"

(gdb) print buf+700
$6 = 0x86a17c "A/8000\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:97
iLBC/8000\r\na=fmtp:97 mode=30\r\na=rtpmap:3 GSM/8000\r\na=rtpmap:101
telephone-event/8000\r\na=fmtp:101 0-16\r\na=silenceSupp:off - - -
-\r\na=ptime:20\r\na=sendrecv\r\n"

(gdb) print buf+800
$7 = 0x86a1e0 "p:101 telephone-event/8000\r\na=fmtp:101
0-16\r\na=silenceSupp:off - - - -\r\na=ptime:20\r\na=sendrecv\r\n"

(gdb) print buf+900
$8 = 0x86a244 "8000\r\na=fmtp:101 0-16,32-36,54\r\na=silenceSupp:off - - -
-\r\n"

(gdb) print buf+1000
$9 = 0x86a2a8 "0\r\na=fmtp:101 0-15\r\n"

(gdb) print buf+1100
$10 = 0x86a30c "000\r\na=ptime:20\r\na=rtpmap:8 PCMA/8000\r\na=rtpmap:4
G723/8000\r\na=rtpmap:18 G729/8000\r\na=rtpmap:2 G726-32/8000\r\na=rtpmap:97
iLBC/8000\r\na=fmtp:97 mode=20\r\na=rtpmap:102 G729E/8000\r\na=rtpmap:100
AAL2-G726-1"...

(gdb) print buf+1200
$11 = 0x86a370 "32/8000\r\na=rtpmap:97 iLBC/8000\r\na=fmtp:97
mode=20\r\na=rtpmap:102 G729E/8000\r\na=rtpmap:100
AAL2-G726-16/8000\r\na=rtpmap:101 telephone-event/8000\r\na=fmtp:101
0-16,32-36,54\r\n"

(gdb) print buf+1300
$12 = 0x86a3d4 "6/8000\r\na=rtpmap:101 telephone-event/8000\r\na=fmtp:101
0-16,32-36,54\r\n"

(gdb) print buf+1400
$13 = 0x86a438 ""

(gdb) print buf+1500
$14 = 0x86a49c "5395257\"\r\nContent-Length: 0\r\n\r\n"


Kelvin Chua


On Thu, Apr 22, 2010 at 4:49 PM, Daniel-Constantin Mierla  wrote:

>  Hi,
>
> if you still have the core file, can you print more of buffer until it gets
> to end of headers? I am curios to see what is wrong with the contact.
>
> Just increase by 100:
>
>  (gdb) print buf+300
> (gdb) print buf+400
> ...
>
> Thanks,
> Daniel
>
>
> On 4/21/10 3:15 PM, Kelvin Chua wrote:
>
> (gdb) bt
> #0  0x2ab61b62779a in update_dialog_dbinfo (cell=0x2ab61c9100f8) at
> dlg_db_handler.c:501
> #1  0x2ab61b628ea8 in dlg_onreply (t=0x7d5228, type= out>, param=) at dlg_handlers.c:361
> #2  0x2ab617965505 in run_trans_callbacks_internal
> (cb_lst=0x2ab61c938830, type=128, trans=0x2ab61c9387c0,
> params=0x7fffec157970) at t_hooks.c:261
> #3  0x2ab61796575e in run_trans_callbacks (type=1, trans=0x88c580,
> req=0x0, rpl=0x0, code=477060464) at t_hooks.c:288
> #4  0x2ab61798ebd1 in relay_reply (t=0x2ab61c9387c0, p_msg= optimized out>, branch=0, msg_status=200,
> cancel_bitmap=0x7fffec157dd4, do_put_on_wait=1) at t_reply.c:1705
> #5  0x2ab617990884 in reply_received (p_msg=0x8f48a8) at t_reply.c:2126
> #6  0x0044760e in forward_reply (msg=0x8f48a8) at forward.c:689
> #7  0x0047fd22 in receive_msg (
> buf=0x869ec0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP
> 10.17.0.202;branch=z9hG4bK75b5.e2a38a16.0\r\nVia: SIP/2.0/UDP
> 10.17.0.200:5060;branch=z9hG4bK730bcb55;rport=5060\r\nRecord-Route:
> \r"..., len=,
> rcv_info=0x7fffec158020) at receive.c:257
> #8  0x00505e2b in udp_rcv_loop () at udp_server.c:520
> #9  0x00455adf in main_loop () at main.c:1447
> #10 0x00456be2 in main (argc=,
> argv=0x7fffec1582e8) at main.c:2251
>
>
>
>  (gdb) print cell
> $1 = (struct dlg_cell *) 0x2ab61c9100f8
>
>
>
>  (gdb) print *cell
> $2 = {ref = 2, next = 0x0, prev = 0x0, h_id = 996587990, h_entry = 1420,
> state = 3, lifetime = 3600, start_ts = 1271816397,
>   dflags = 1, sflags = 0, toroute = 0, from_rr_nb = 0, tl = {next = 0x0,
> prev = 0x0, timeout = 0}, callid = {
> s = 0x2ab61c910238 
> "0901b21e13a60e0247988caf7d72f...@10.17.0.200sip:029147...@10.17.0.200sip:4...@hiddendomain.edusip:4...@10.17.40.77:5060;user=phone;transport=udpent-Length:
> 0\r\n\r\n"<0901b21e13a60e0247988caf7d72f...@10.17.0.200sip:029147...@10.17.0.200sip:4...@hiddendomain.edusip:4...@10.17.40.77:5060;user=phone;transport=udpent-Length:0%5Cr%5Cn%5Cr%5Cn>,
> len = 44}, from_uri = {
> s = 0x2ab61c910264 
> "sip:029147...@10.17.0.200sip:4...@hiddendomain.edusip:4...@10.17.40.77:5060;user=phone;transport=udpent-Length:
> 0\r\n\r\n",
> len = 25}, to_uri = {
> s = 0x2ab61c91027d 
> "sip:4...@hiddendomain.edusip:4...@10.17.40.77:5060;user=phone;transport=udpent-Length:
> 0\r\n\r\n",
> len = 19},
>   req_uri = {s = 0x2ab61c910290 
> "sip:4...@10.17.40.77:5060;user=phone;transport=udpent-Length:
> 0\r\n\r\n",
> len = 50}, tag = {{
>   s = 0x2ab61c91c488 
> "as50d7852dsip:029147...@10.17.0.200\034�*",
> len = 10}, {s = 0x0, len = 0}}, cseq = {{
>   s = 0x2ab61c857950 "10213331\b", len = 3}, {s = 0x0, len = 0}},

Re: [SR-Users] possible bug with dialog module

2010-04-22 Thread Timo Reimann

Hey Daniel,

Daniel-Constantin Mierla wrote:
> thanks for troubleshooting. I committed the patch that moves setting of
> bind_addr before any error case in populate_leg_info(). I backported to
> kamailio_3.0 branch as well.
> 
> Kelvin, can you get the lasted git version for branch kamailio_3.0 and
> test?

Thanks Daniel. What about applying the bugfix to Kamailio 1.5 (and maybe
even 1.[43]) too? I see that 1.5 is less ambitious to "goto error0" and
thereby skip the assignment but it may still happen (for instance, if
CSeq parsing fails). 1.[43]'s "populate_leg_info" function look more
similar to 3.0's and may definitely crash as well.

And if we decide to backport the patch: Shall we wait for Kelvin to test
the 3.0 patch first to make sure it really works?

Cheers,

--Timo

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] possible bug with dialog module

2010-04-22 Thread Daniel-Constantin Mierla


Hi,

if you still have the core file, can you print more of buffer until it 
gets to end of headers? I am curios to see what is wrong with the contact.


Just increase by 100:

(gdb) print buf+300
(gdb) print buf+400
...

Thanks,
Daniel


On 4/21/10 3:15 PM, Kelvin Chua wrote:

(gdb) bt
#0  0x2ab61b62779a in update_dialog_dbinfo (cell=0x2ab61c9100f8) 
at dlg_db_handler.c:501
#1  0x2ab61b628ea8 in dlg_onreply (t=0x7d5228, type=optimized out>, param=) at dlg_handlers.c:361
#2  0x2ab617965505 in run_trans_callbacks_internal 
(cb_lst=0x2ab61c938830, type=128, trans=0x2ab61c9387c0,

params=0x7fffec157970) at t_hooks.c:261
#3  0x2ab61796575e in run_trans_callbacks (type=1, trans=0x88c580, 
req=0x0, rpl=0x0, code=477060464) at t_hooks.c:288
#4  0x2ab61798ebd1 in relay_reply (t=0x2ab61c9387c0, p_msg=optimized out>, branch=0, msg_status=200,

cancel_bitmap=0x7fffec157dd4, do_put_on_wait=1) at t_reply.c:1705
#5  0x2ab617990884 in reply_received (p_msg=0x8f48a8) at 
t_reply.c:2126

#6  0x0044760e in forward_reply (msg=0x8f48a8) at forward.c:689
#7  0x0047fd22 in receive_msg (
buf=0x869ec0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 
10.17.0.202;branch=z9hG4bK75b5.e2a38a16.0\r\nVia: SIP/2.0/UDP 
10.17.0.200:5060;branch=z9hG4bK730bcb55;rport=5060\r\nRecord-Route: 
\r"..., len=out>,

rcv_info=0x7fffec158020) at receive.c:257
#8  0x00505e2b in udp_rcv_loop () at udp_server.c:520
#9  0x00455adf in main_loop () at main.c:1447
#10 0x00456be2 in main (argc=, 
argv=0x7fffec1582e8) at main.c:2251




(gdb) print cell
$1 = (struct dlg_cell *) 0x2ab61c9100f8



(gdb) print *cell
$2 = {ref = 2, next = 0x0, prev = 0x0, h_id = 996587990, h_entry = 
1420, state = 3, lifetime = 3600, start_ts = 1271816397,
  dflags = 1, sflags = 0, toroute = 0, from_rr_nb = 0, tl = {next = 
0x0, prev = 0x0, timeout = 0}, callid = {
s = 0x2ab61c910238 
"0901b21e13a60e0247988caf7d72f...@10.17.0.200sip:029147...@10.17.0.200sip:4...@hiddendomain.edusip:4...@10.17.40.77:5060;user=phone;transport=udpent-Length: 
0\r\n\r\n", len = 44}, from_uri = {
s = 0x2ab61c910264 
"sip:029147...@10.17.0.200sip:4...@hiddendomain.edusip:4...@10.17.40.77:5060;user=phone;transport=udpent-Length: 
0\r\n\r\n", len = 25}, to_uri = {
s = 0x2ab61c91027d 
"sip:4...@hiddendomain.edusip:4...@10.17.40.77:5060;user=phone;transport=udpent-Length: 
0\r\n\r\n", len = 19},
  req_uri = {s = 0x2ab61c910290 
"sip:4...@10.17.40.77:5060;user=phone;transport=udpent-Length: 
0\r\n\r\n", len = 50}, tag = {{
  s = 0x2ab61c91c488 "as50d7852dsip:029147...@10.17.0.200 
\034�*", len = 10}, {s = 
0x0, len = 0}}, cseq = {{
  s = 0x2ab61c857950 "10213331\b", len = 3}, {s = 0x0, len = 0}}, 
route_set = {{s = 0x0, len = 0}, {s = 0x0, len = 0}},
  contact = {{s = 0x2ab61c91c492 "sip:029147...@10.17.0.200 
\034�*", len = 25}, {s = 0x0, len 
= 0}}, bind_addr = {0x88c580, 0x0},

  cbs = {first = 0x0, types = 0}, profile_links = 0x0}



(gdb) frame 7
#7  0x0047fd22 in receive_msg (
buf=0x869ec0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 
10.17.0.202;branch=z9hG4bK75b5.e2a38a16.0\r\nVia: SIP/2.0/UDP 
10.17.0.200:5060;branch=z9hG4bK730bcb55;rport=5060\r\nRecord-Route: 
\r"..., len=out>,

rcv_info=0x7fffec158020) at receive.c:257
257 forward_reply(msg);



(gdb) print buf+100
$3 = 0x869f24 
".200:5060;branch=z9hG4bK730bcb55;rport=5060\r\nRecord-Route: 
\r\nFrom: \"029147089\" 
>;tag=as50d7852d\r\nTo: 
>;tag=4735210"...




(gdb) print buf+200
$4 = 0x869f88 "\nFrom: \"029147089\" >;tag=as50d7852d\r\nTo: 
>;tag=473521065\r\nCall-ID: 
0901b21e13a60e0247988caf7d72f...@10.17.0.200 
\r\nCSeq: 102 
INVITE\r\nServer: Cisco ATA 186  "...




(gdb) print buf+300
$5 = 0x869fec "65\r\nCall-ID: 
0901b21e13a60e0247988caf7d72f...@10.17.0.200 
\r\nCSeq: 102 
INVITE\r\nServer: Cisco ATA 186  v3.2.0 atasip (04A)\r\nAllow: 
ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER, PRACK, U"...


Kelvin Chua


On Wed, Apr 21, 2010 at 7:22 PM, Daniel-Constantin Mierla 
mailto:mico...@gmail.com>> wrote:


Hello,


On 4/21/10 12:23 PM, Kelvin Chua wrote:

hi daniel,

i'm not using git version. so maybe i'm missing some patches. can
you confirm if what i am
experiencing is the same problem and the fix is indeed available
from the git version? thanks


I recommend using at least 3.0.1, as a matter of fact 3.0.2 should
be released soon.

Can you please print the content of cell adn more of the reply in
gdb, here are the commands:


gdb /path/to/kamailio core_file

print cell

print *cell

frame 7

print buf+100

print buf+200

print buf

Re: [SR-Users] possible bug with dialog module

2010-04-22 Thread Daniel-Constantin Mierla


Hi Timo,

thanks for troubleshooting. I committed the patch that moves setting of 
bind_addr before any error case in populate_leg_info(). I backported to 
kamailio_3.0 branch as well.


Kelvin, can you get the lasted git version for branch kamailio_3.0 and test?

Thanks,
Daniel

On 4/22/10 1:21 AM, Timo Reimann wrote:

Hello,


Kelvin Chua wrote:
   

(gdb) bt
#0  0x2ab61b62779a in update_dialog_dbinfo (cell=0x2ab61c9100f8) at
dlg_db_handler.c:501
 

This corresponds to

   SET_STR_VALUE(values+8, cell->bind_addr[DLG_CALLEE_LEG]->sock_str);

so assumingly sip-router crashes when it tries to access the callee's
bound address's sock_str...


   

#1  0x2ab61b628ea8 in dlg_onreply (t=0x7d5228, type=, param=) at dlg_handlers.c:361
#2  0x2ab617965505 in run_trans_callbacks_internal
(cb_lst=0x2ab61c938830, type=128, trans=0x2ab61c9387c0,

(gdb) print cell
$1 = (struct dlg_cell *) 0x2ab61c9100f8



(gdb) print *cell
0}}, bind_addr = {0x88c580, 0x0},
   cbs = {first = 0x0, types = 0}, profile_links = 0x0}
 

... as supported by the fact that bind_addr's second field
(DLG_CALLEE_LEG) is 0.

Why does the segfault happen?

Let's trace the code path: The initial error message

"bad sip message or missing Contact hdr"

occurred in dlg_handlers.c, line 218, which makes this piece of code's
surrounding function "populate_leg_info" return prematurely (by means of
"goto error0"). Specifically, this implies that the code at the end of
the function on line 272

   dlg->bind_addr[leg] = msg->rcv.bind_address;

isn't carried out anymore, leaving the callee's bound address associated
with the given dialog unassigned. (This happens to be the only occasion
where the bound address is assigned.) Instead, execution drops back to
the "dlg_onreply" function and proceeds to line 361, thereby calling the
database update function:

   update_dialog_dbinfo(dlg);

which directly leads to the segfaulting code location.


AFAICS, "update_dialog_dbinfo" is dereferencing a possibly null memory
location at the dialog data in question only, so one way to prevent the
segfault from happening is to move the bound address assignment before
any failing code in the function. This should make sure that some
accessible bound address is stored in any case.


Cheers,

--Timo
   


--
Daniel-Constantin Mierla * http://www.asipto.com/ * 
http://twitter.com/miconda * 
http://www.linkedin.com/in/danielconstantinmierla


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] possible bug with dialog module

2010-04-21 Thread Timo Reimann

Hello,

Kelvin Chua wrote:
> (gdb) bt
> #0  0x2ab61b62779a in update_dialog_dbinfo (cell=0x2ab61c9100f8) at
> dlg_db_handler.c:501

This corresponds to

  SET_STR_VALUE(values+8, cell->bind_addr[DLG_CALLEE_LEG]->sock_str);

so assumingly sip-router crashes when it tries to access the callee's
bound address's sock_str...

> #1  0x2ab61b628ea8 in dlg_onreply (t=0x7d5228, type= out>, param=) at dlg_handlers.c:361
> #2  0x2ab617965505 in run_trans_callbacks_internal
> (cb_lst=0x2ab61c938830, type=128, trans=0x2ab61c9387c0, 
> 
> (gdb) print cell
> $1 = (struct dlg_cell *) 0x2ab61c9100f8
> 
> 
> 
> (gdb) print *cell
> 0}}, bind_addr = {0x88c580, 0x0}, 
>   cbs = {first = 0x0, types = 0}, profile_links = 0x0}

... as supported by the fact that bind_addr's second field
(DLG_CALLEE_LEG) is 0.

Why does the segfault happen?

Let's trace the code path: The initial error message

"bad sip message or missing Contact hdr"

occurred in dlg_handlers.c, line 218, which makes this piece of code's
surrounding function "populate_leg_info" return prematurely (by means of
"goto error0"). Specifically, this implies that the code at the end of
the function on line 272

  dlg->bind_addr[leg] = msg->rcv.bind_address;

isn't carried out anymore, leaving the callee's bound address associated
with the given dialog unassigned. (This happens to be the only occasion
where the bound address is assigned.) Instead, execution drops back to
the "dlg_onreply" function and proceeds to line 361, thereby calling the
database update function:

  update_dialog_dbinfo(dlg);

which directly leads to the segfaulting code location.

AFAICS, "update_dialog_dbinfo" is dereferencing a possibly null memory
location at the dialog data in question only, so one way to prevent the
segfault from happening is to move the bound address assignment before
any failing code in the function. This should make sure that some
accessible bound address is stored in any case.

Cheers,

--Timo

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] possible bug with dialog module

2010-04-21 Thread Kelvin Chua

(gdb) bt
#0  0x2ab61b62779a in update_dialog_dbinfo (cell=0x2ab61c9100f8) at
dlg_db_handler.c:501
#1  0x2ab61b628ea8 in dlg_onreply (t=0x7d5228, type=, param=) at dlg_handlers.c:361
#2  0x2ab617965505 in run_trans_callbacks_internal
(cb_lst=0x2ab61c938830, type=128, trans=0x2ab61c9387c0,
params=0x7fffec157970) at t_hooks.c:261
#3  0x2ab61796575e in run_trans_callbacks (type=1, trans=0x88c580,
req=0x0, rpl=0x0, code=477060464) at t_hooks.c:288
#4  0x2ab61798ebd1 in relay_reply (t=0x2ab61c9387c0, p_msg=, branch=0, msg_status=200,
cancel_bitmap=0x7fffec157dd4, do_put_on_wait=1) at t_reply.c:1705
#5  0x2ab617990884 in reply_received (p_msg=0x8f48a8) at t_reply.c:2126
#6  0x0044760e in forward_reply (msg=0x8f48a8) at forward.c:689
#7  0x0047fd22 in receive_msg (
buf=0x869ec0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP
10.17.0.202;branch=z9hG4bK75b5.e2a38a16.0\r\nVia: SIP/2.0/UDP
10.17.0.200:5060;branch=z9hG4bK730bcb55;rport=5060\r\nRecord-Route:
\r"..., len=,
rcv_info=0x7fffec158020) at receive.c:257
#8  0x00505e2b in udp_rcv_loop () at udp_server.c:520
#9  0x00455adf in main_loop () at main.c:1447
#10 0x00456be2 in main (argc=,
argv=0x7fffec1582e8) at main.c:2251



(gdb) print cell
$1 = (struct dlg_cell *) 0x2ab61c9100f8



(gdb) print *cell
$2 = {ref = 2, next = 0x0, prev = 0x0, h_id = 996587990, h_entry = 1420,
state = 3, lifetime = 3600, start_ts = 1271816397,
  dflags = 1, sflags = 0, toroute = 0, from_rr_nb = 0, tl = {next = 0x0,
prev = 0x0, timeout = 0}, callid = {
s = 0x2ab61c910238 "0901b21e13a60e0247988caf7d72f...@10.17.0.200sip
:029147...@10.17.0.200sip:4...@hiddendomain.edusip:4...@10.17.40.77:5060;user=phone;transport=udpent-Length:
0\r\n\r\n", len = 44}, from_uri = {
s = 0x2ab61c910264 "sip:029147...@10.17.0.200sip
:4...@hiddendomain.edusip:4...@10.17.40.77:5060;user=phone;transport=udpent-Length:
0\r\n\r\n", len = 25}, to_uri = {
s = 0x2ab61c91027d
"sip:4...@hiddendomain.edusip:4...@10.17.40.77:5060;user=phone;transport=udpent-Length:
0\r\n\r\n", len = 19},
  req_uri = {s = 0x2ab61c910290
"sip:4...@10.17.40.77:5060;user=phone;transport=udpent-Length:
0\r\n\r\n", len = 50}, tag = {{
  s = 0x2ab61c91c488
"as50d7852dsip:029147...@10.17.0.200\034�*",
len = 10}, {s = 0x0, len = 0}}, cseq = {{
  s = 0x2ab61c857950 "10213331\b", len = 3}, {s = 0x0, len = 0}},
route_set = {{s = 0x0, len = 0}, {s = 0x0, len = 0}},
  contact = {{s = 0x2ab61c91c492
"sip:029147...@10.17.0.200\034�*",
len = 25}, {s = 0x0, len = 0}}, bind_addr = {0x88c580, 0x0},
  cbs = {first = 0x0, types = 0}, profile_links = 0x0}



(gdb) frame 7
#7  0x0047fd22 in receive_msg (
buf=0x869ec0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP
10.17.0.202;branch=z9hG4bK75b5.e2a38a16.0\r\nVia: SIP/2.0/UDP
10.17.0.200:5060;branch=z9hG4bK730bcb55;rport=5060\r\nRecord-Route:
\r"..., len=,
rcv_info=0x7fffec158020) at receive.c:257
257 forward_reply(msg);



(gdb) print buf+100
$3 = 0x869f24 ".200:5060;branch=z9hG4bK730bcb55;rport=5060\r\nRecord-Route:
\r\nFrom: \"029147089\" <
sip:029147...@10.17.0.200 >;tag=as50d7852d\r\nTo:
>;tag=4735210"...



(gdb) print buf+200
$4 = 0x869f88 "\nFrom: \"029147089\"
>;tag=as50d7852d\r\nTo:
>;tag=473521065\r\nCall-ID:
0901b21e13a60e0247988caf7d72f...@10.17.0.200\r\ncseq: 102 INVITE\r\nServer:
Cisco ATA 186  "...



(gdb) print buf+300
$5 = 0x869fec "65\r\nCall-ID:
0901b21e13a60e0247988caf7d72f...@10.17.0.200\r\ncseq:
102 INVITE\r\nServer: Cisco ATA 186  v3.2.0 atasip (04A)\r\nAllow: ACK,
BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER, PRACK, U"...

Kelvin Chua


On Wed, Apr 21, 2010 at 7:22 PM, Daniel-Constantin Mierla  wrote:

>  Hello,
>
>
> On 4/21/10 12:23 PM, Kelvin Chua wrote:
>
> hi daniel,
>
>  i'm not using git version. so maybe i'm missing some patches. can you
> confirm if what i am
> experiencing is the same problem and the fix is indeed available from the
> git version? thanks
>
>
> I recommend using at least 3.0.1, as a matter of fact 3.0.2 should be
> released soon.
>
> Can you please print the content of cell adn more of the reply in gdb, here
> are the commands:
>
>
> gdb /path/to/kamailio core_file
>
> print cell
>
> print *cell
>
> frame 7
>
> print buf+100
>
> print buf+200
>
> print buf+300
>
> Thanks,
> Daniel
>
>
>  here is the backtrace:
>
>  #0  0x2ab61b62779a in update_dialog_dbinfo (cell=0x2ab61c9100f8) at
> dlg_db_handler.c:501
> #1  0x2ab61b628ea8 in dlg_onreply (t=0x7d5228, type= out>, param=) at dlg_handlers.c:361
> #2  0x2ab617965505 in run_trans_callbacks_internal
> (cb_lst=0x2ab61c938830, type=128, trans=0x2ab61c9387c0,
> params=0x7fffec157970) at t_hooks.c:261
> #3  0x2ab61796575e in run_trans_callbacks (type=1, trans=0x88c580,
> req=0x0, rpl=0x0, code=477060464) at t_hooks.c:288
> #4  0x2ab61798ebd1 in relay_reply (t=0x2ab61c9387c0, p_msg= optimized out>, branch=0, msg_status=200,
> cancel_bitmap=0x7fffec157dd4, do_put_on_wait=1) at t_reply.c:1705

Re: [SR-Users] possible bug with dialog module

2010-04-21 Thread Daniel-Constantin Mierla




On 4/21/10 1:31 PM, Iñaki Baz Castillo wrote:

2010/4/21 Daniel-Constantin Mierla:
   

Hello,

are you using the latest git version of branch kamailio_3.0? It was a fix to
dialog after the 3.0.0 release, adding some sanity checks for broken
messages:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=787fabb1e0085355aa1eeb77d5f17e7940f4ed3c
 

Hi Daniel, these changes are already present in Kamailio 1.5 branch, right?

   

yes, they are.

Cheers,
Daniel

--
Daniel-Constantin Mierla * http://www.asipto.com/ * 
http://twitter.com/miconda * 
http://www.linkedin.com/in/danielconstantinmierla


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] possible bug with dialog module

2010-04-21 Thread Iñaki Baz Castillo

2010/4/21 Daniel-Constantin Mierla :
> Hello,
>
> are you using the latest git version of branch kamailio_3.0? It was a fix to
> dialog after the 3.0.0 release, adding some sanity checks for broken
> messages:
> http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=787fabb1e0085355aa1eeb77d5f17e7940f4ed3c

Hi Daniel, these changes are already present in Kamailio 1.5 branch, right?



-- 
Iñaki Baz Castillo


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] possible bug with dialog module

2010-04-21 Thread Daniel-Constantin Mierla


Hello,

On 4/21/10 12:23 PM, Kelvin Chua wrote:

hi daniel,

i'm not using git version. so maybe i'm missing some patches. can you 
confirm if what i am
experiencing is the same problem and the fix is indeed available from 
the git version? thanks


I recommend using at least 3.0.1, as a matter of fact 3.0.2 should be 
released soon.


Can you please print the content of cell adn more of the reply in gdb, 
here are the commands:


gdb /path/to/kamailio core_file

print cell

print *cell

frame 7

print buf+100

print buf+200

print buf+300

Thanks,
Daniel


here is the backtrace:

#0  0x2ab61b62779a in update_dialog_dbinfo (cell=0x2ab61c9100f8) 
at dlg_db_handler.c:501
#1  0x2ab61b628ea8 in dlg_onreply (t=0x7d5228, type=optimized out>, param=) at dlg_handlers.c:361
#2  0x2ab617965505 in run_trans_callbacks_internal 
(cb_lst=0x2ab61c938830, type=128, trans=0x2ab61c9387c0,

params=0x7fffec157970) at t_hooks.c:261
#3  0x2ab61796575e in run_trans_callbacks (type=1, trans=0x88c580, 
req=0x0, rpl=0x0, code=477060464) at t_hooks.c:288
#4  0x2ab61798ebd1 in relay_reply (t=0x2ab61c9387c0, p_msg=optimized out>, branch=0, msg_status=200,

cancel_bitmap=0x7fffec157dd4, do_put_on_wait=1) at t_reply.c:1705
#5  0x2ab617990884 in reply_received (p_msg=0x8f48a8) at 
t_reply.c:2126

#6  0x0044760e in forward_reply (msg=0x8f48a8) at forward.c:689
#7  0x0047fd22 in receive_msg (
buf=0x869ec0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 
10.17.0.202;branch=z9hG4bK75b5.e2a38a16.0\r\nVia: SIP/2.0/UDP 
10.17.0.200:5060;branch=z9hG4bK730bcb55;rport=5060\r\nRecord-Route: 
\r"..., len=out>,

rcv_info=0x7fffec158020) at receive.c:257
#8  0x00505e2b in udp_rcv_loop () at udp_server.c:520
#9  0x00455adf in main_loop () at main.c:1447
#10 0x00456be2 in main (argc=, 
argv=0x7fffec1582e8) at main.c:2251



Kelvin Chua


On Wed, Apr 21, 2010 at 6:04 PM, Daniel-Constantin Mierla 
mailto:mico...@gmail.com>> wrote:


Hello,

are you using the latest git version of branch kamailio_3.0? It
was a fix to dialog after the 3.0.0 release, adding some sanity
checks for broken messages:

http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=787fabb1e0085355aa1eeb77d5f17e7940f4ed3c

On the other hand, I see you got a core dump file:
Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28507]: ALERT:
 [main.c:722]: child process 28511 exited by a signal 11
Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28507]: ALERT:
 [main.c:725]: core was generated

Locate the core file and sent the backtrace. The core is either in
root '/' folder or in working directory (if you provided by -w
parameter).

Use the gdb:

gdb /path/to/kamailio core_file

then do bt and send here.

Thanks,
Daniel

On 4/21/10 11:38 AM, Kelvin Chua wrote:

ok, i'll enable debug for now.
but if it's indeed a buggy UA, the dialog module should not
have crashed
but instead dropped the dialog/session and moved on, something i
think
we need to address to be more resilient.

i hope i catch the culprit when this happens again.

Kelvin Chua


On Wed, Apr 21, 2010 at 5:33 PM, Iñaki Baz Castillo
mailto:i...@aliax.net>> wrote:

2010/4/21 Kelvin Chua mailto:kel...@gmail.com>>:
> i wonder if anybody from list is also experiencing this?

Perhaps in your case you have a buggy UA setting an invalid
Contact
header and it causes Kamailio to crash, maybe the reason
others have
not detected same issue.

Could you get some SIP traces until the problem occurs again?
or perhaps could you enable the debug?

--
Iñaki Baz Castillo
mailto:i...@aliax.net>>



___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org

http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


-- 
Daniel-Constantin Mierla * http://www.asipto.com/ *

http://twitter.com/miconda *
http://www.linkedin.com/in/danielconstantinmierla




--
Daniel-Constantin Mierla * http://www.asipto.com/ * 
http://twitter.com/miconda * 
http://www.linkedin.com/in/danielconstantinmierla
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] possible bug with dialog module

2010-04-21 Thread Kelvin Chua

hi daniel,

i'm not using git version. so maybe i'm missing some patches. can you
confirm if what i am
experiencing is the same problem and the fix is indeed available from the
git version? thanks

here is the backtrace:

#0  0x2ab61b62779a in update_dialog_dbinfo (cell=0x2ab61c9100f8) at
dlg_db_handler.c:501
#1  0x2ab61b628ea8 in dlg_onreply (t=0x7d5228, type=, param=) at dlg_handlers.c:361
#2  0x2ab617965505 in run_trans_callbacks_internal
(cb_lst=0x2ab61c938830, type=128, trans=0x2ab61c9387c0,
params=0x7fffec157970) at t_hooks.c:261
#3  0x2ab61796575e in run_trans_callbacks (type=1, trans=0x88c580,
req=0x0, rpl=0x0, code=477060464) at t_hooks.c:288
#4  0x2ab61798ebd1 in relay_reply (t=0x2ab61c9387c0, p_msg=, branch=0, msg_status=200,
cancel_bitmap=0x7fffec157dd4, do_put_on_wait=1) at t_reply.c:1705
#5  0x2ab617990884 in reply_received (p_msg=0x8f48a8) at t_reply.c:2126
#6  0x0044760e in forward_reply (msg=0x8f48a8) at forward.c:689
#7  0x0047fd22 in receive_msg (
buf=0x869ec0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP
10.17.0.202;branch=z9hG4bK75b5.e2a38a16.0\r\nVia: SIP/2.0/UDP
10.17.0.200:5060;branch=z9hG4bK730bcb55;rport=5060\r\nRecord-Route:
\r"..., len=,
rcv_info=0x7fffec158020) at receive.c:257
#8  0x00505e2b in udp_rcv_loop () at udp_server.c:520
#9  0x00455adf in main_loop () at main.c:1447
#10 0x00456be2 in main (argc=,
argv=0x7fffec1582e8) at main.c:2251


Kelvin Chua


On Wed, Apr 21, 2010 at 6:04 PM, Daniel-Constantin Mierla  wrote:

>  Hello,
>
> are you using the latest git version of branch kamailio_3.0? It was a fix
> to dialog after the 3.0.0 release, adding some sanity checks for broken
> messages:
>
> http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=787fabb1e0085355aa1eeb77d5f17e7940f4ed3c
>
> On the other hand, I see you got a core dump file:
> Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28507]: ALERT: 
> [main.c:722]: child process 28511 exited by a signal 11
> Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28507]: ALERT: 
> [main.c:725]: core was generated
>
> Locate the core file and sent the backtrace. The core is either in root '/'
> folder or in working directory (if you provided by -w parameter).
>
> Use the gdb:
>
> gdb /path/to/kamailio core_file
>
> then do bt and send here.
>
> Thanks,
> Daniel
>
> On 4/21/10 11:38 AM, Kelvin Chua wrote:
>
> ok, i'll enable debug for now.
> but if it's indeed a buggy UA, the dialog module should not have crashed
> but instead dropped the dialog/session and moved on, something i think
> we need to address to be more resilient.
>
>  i hope i catch the culprit when this happens again.
>
> Kelvin Chua
>
>
> On Wed, Apr 21, 2010 at 5:33 PM, Iñaki Baz Castillo  wrote:
>
>> 2010/4/21 Kelvin Chua :
>>  > i wonder if anybody from list is also experiencing this?
>>
>> Perhaps in your case you have a buggy UA setting an invalid Contact
>> header and it causes Kamailio to crash, maybe the reason others have
>> not detected same issue.
>>
>> Could you get some SIP traces until the problem occurs again?
>> or perhaps could you enable the debug?
>>
>> --
>>  Iñaki Baz Castillo
>> 
>>
>
>
> ___
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-us...@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
> --
> Daniel-Constantin Mierla * http://www.asipto.com/ *
> http://twitter.com/miconda *
> http://www.linkedin.com/in/danielconstantinmierla
>
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] possible bug with dialog module

2010-04-21 Thread Daniel-Constantin Mierla


Hello,

are you using the latest git version of branch kamailio_3.0? It was a 
fix to dialog after the 3.0.0 release, adding some sanity checks for 
broken messages:

http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=787fabb1e0085355aa1eeb77d5f17e7940f4ed3c

On the other hand, I see you got a core dump file:
Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28507]: ALERT:  
[main.c:722]: child process 28511 exited by a signal 11
Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28507]: ALERT:  
[main.c:725]: core was generated


Locate the core file and sent the backtrace. The core is either in root 
'/' folder or in working directory (if you provided by -w parameter).


Use the gdb:

gdb /path/to/kamailio core_file

then do bt and send here.

Thanks,
Daniel

On 4/21/10 11:38 AM, Kelvin Chua wrote:

ok, i'll enable debug for now.
but if it's indeed a buggy UA, the dialog module should not have crashed
but instead dropped the dialog/session and moved on, something i think
we need to address to be more resilient.

i hope i catch the culprit when this happens again.

Kelvin Chua


On Wed, Apr 21, 2010 at 5:33 PM, Iñaki Baz Castillo > wrote:


2010/4/21 Kelvin Chua mailto:kel...@gmail.com>>:
> i wonder if anybody from list is also experiencing this?

Perhaps in your case you have a buggy UA setting an invalid Contact
header and it causes Kamailio to crash, maybe the reason others have
not detected same issue.

Could you get some SIP traces until the problem occurs again?
or perhaps could you enable the debug?

--
Iñaki Baz Castillo
mailto:i...@aliax.net>>



___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
   


--
Daniel-Constantin Mierla * http://www.asipto.com/ * 
http://twitter.com/miconda * 
http://www.linkedin.com/in/danielconstantinmierla
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] possible bug with dialog module

2010-04-21 Thread Kelvin Chua

ok, i'll enable debug for now.
but if it's indeed a buggy UA, the dialog module should not have crashed
but instead dropped the dialog/session and moved on, something i think
we need to address to be more resilient.

i hope i catch the culprit when this happens again.

Kelvin Chua

On Wed, Apr 21, 2010 at 5:33 PM, Iñaki Baz Castillo  wrote:

> 2010/4/21 Kelvin Chua :
> > i wonder if anybody from list is also experiencing this?
>
> Perhaps in your case you have a buggy UA setting an invalid Contact
> header and it causes Kamailio to crash, maybe the reason others have
> not detected same issue.
>
> Could you get some SIP traces until the problem occurs again?
> or perhaps could you enable the debug?
>
> --
> Iñaki Baz Castillo
> 
>
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] possible bug with dialog module

2010-04-21 Thread Iñaki Baz Castillo

2010/4/21 Kelvin Chua :
> i wonder if anybody from list is also experiencing this?

Perhaps in your case you have a buggy UA setting an invalid Contact
header and it causes Kamailio to crash, maybe the reason others have
not detected same issue.

Could you get some SIP traces until the problem occurs again?
or perhaps could you enable the debug?

-- 
Iñaki Baz Castillo


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] possible bug with dialog module

2010-04-21 Thread Kelvin Chua

yeah lots of traffic.
so there's no way of telling whether that particular BYE caused the crashed
or not.
unless i enable debug for the server.

besides, you're right it might just be a simple case of receiving a BYE for
an expired
dialog or something, doesn't seem too fishy at all. i wonder if anybody from
the list
is also experiencing this?

Kelvin Chua


On Wed, Apr 21, 2010 at 5:16 PM, Iñaki Baz Castillo  wrote:

> 2010/4/21 Kelvin Chua :
> > hi inaki,
> > unfortunately since i am not expecting any segfaults from kamailio, i
> have
> > very little
> > debug info, only those spurted out by syslog. not been using 1.5 for some
> > time now.
> > bad news, happened twice today. in a
> > span of 3 hours. seems like an inbound BYE. here is the other instance:
>
> > Apr 21 11:58:56 kamvm-1 /usr/local/sbin/kamailio[2526]: WARNING: dialog
> > [dlg_handlers.c:806]: unable to find dialog for BYE with route param
> > 'e34.a5ceb3d5' [1086:1564208218]
>
> This just means that Kamailio has received a BYE thtat doesn't match
> with an existing dialog. Perhaps the dialog expired, a previous BYE
> from the other side was already received or kamailio was restarted and
> doesn't keep the dialogs info in database.
>
> Are you sure that the folowing log lines occur due to the previous BYE
> line? has the server lot of traffic?
>
>
> > Apr 21 11:58:56 kamvm-1 /usr/local/sbin/kamailio[2526]: ERROR: dialog
> > [dlg_handlers.c:218]: bad sip message or missing Contact hdr
> > Apr 21 11:58:56 kamvm-1 /usr/local/sbin/kamailio[2526]: ERROR: dialog
> > [dlg_handlers.c:350]: could not add further info to the dialog
> > Apr 21 11:58:56 kamvm-1 kernel: kamailio[2526]: segfault at
> 0088
> > rip 2b4a039f979a rsp 7fff0f0472c0 error 4
> > Apr 21 11:59:01 kamvm-1 /usr/local/sbin/kamailio[2524]: ALERT: 
> > [main.c:722]: child process 2526 exited by a signal 11
> > Apr 21 11:59:01 kamvm-1 /usr/local/sbin/kamailio[2524]: ALERT: 
> > [main.c:725]: core was generated
> >
> > Kelvin Chua
> >
> >
> > On Wed, Apr 21, 2010 at 5:06 PM, Iñaki Baz Castillo 
> wrote:
> >>
> >> 2010/4/21 Kelvin Chua :
> >> > currently using kamailio 3.0 with around 1000 users.
> >> > Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28511]: ERROR: dialog
> >> > [dlg_handlers.c:218]: bad sip message or missing Contact hdr
> >> > Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28511]: ERROR: dialog
> >> > [dlg_handlers.c:350]: could not add further info to the dialog
> >> > Apr 21 10:19:57 kamvm-1 kernel: kamailio[28511]: segfault at
> >> > 0088 rip 2ab61b62779a rsp 7fffec157440 error 4
> >> > Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28507]: ALERT: 
> >> > [main.c:722]: child process 28511 exited by a signal 11
> >> > Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28507]: ALERT: 
> >> > [main.c:725]: core was generated
> >>
> >> Oh my god!
> >> Let me two question:
> >>
> >> - Are you able to determine if the problem occurs when handling an
> >> INVITE or a response?
> >> - Do you know if some occurs in Kamailio 1.5?
> >>
> >>
> >>
> >> --
> >> Iñaki Baz Castillo
> >> 
> >
> >
>
>
>
> --
> Iñaki Baz Castillo
> 
>
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] possible bug with dialog module

2010-04-21 Thread Iñaki Baz Castillo

2010/4/21 Kelvin Chua :
> hi inaki,
> unfortunately since i am not expecting any segfaults from kamailio, i have
> very little
> debug info, only those spurted out by syslog. not been using 1.5 for some
> time now.
> bad news, happened twice today. in a
> span of 3 hours. seems like an inbound BYE. here is the other instance:

> Apr 21 11:58:56 kamvm-1 /usr/local/sbin/kamailio[2526]: WARNING: dialog
> [dlg_handlers.c:806]: unable to find dialog for BYE with route param
> 'e34.a5ceb3d5' [1086:1564208218]

This just means that Kamailio has received a BYE thtat doesn't match
with an existing dialog. Perhaps the dialog expired, a previous BYE
from the other side was already received or kamailio was restarted and
doesn't keep the dialogs info in database.

Are you sure that the folowing log lines occur due to the previous BYE
line? has the server lot of traffic?


> Apr 21 11:58:56 kamvm-1 /usr/local/sbin/kamailio[2526]: ERROR: dialog
> [dlg_handlers.c:218]: bad sip message or missing Contact hdr
> Apr 21 11:58:56 kamvm-1 /usr/local/sbin/kamailio[2526]: ERROR: dialog
> [dlg_handlers.c:350]: could not add further info to the dialog
> Apr 21 11:58:56 kamvm-1 kernel: kamailio[2526]: segfault at 0088
> rip 2b4a039f979a rsp 7fff0f0472c0 error 4
> Apr 21 11:59:01 kamvm-1 /usr/local/sbin/kamailio[2524]: ALERT: 
> [main.c:722]: child process 2526 exited by a signal 11
> Apr 21 11:59:01 kamvm-1 /usr/local/sbin/kamailio[2524]: ALERT: 
> [main.c:725]: core was generated
>
> Kelvin Chua
>
>
> On Wed, Apr 21, 2010 at 5:06 PM, Iñaki Baz Castillo  wrote:
>>
>> 2010/4/21 Kelvin Chua :
>> > currently using kamailio 3.0 with around 1000 users.
>> > Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28511]: ERROR: dialog
>> > [dlg_handlers.c:218]: bad sip message or missing Contact hdr
>> > Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28511]: ERROR: dialog
>> > [dlg_handlers.c:350]: could not add further info to the dialog
>> > Apr 21 10:19:57 kamvm-1 kernel: kamailio[28511]: segfault at
>> > 0088 rip 2ab61b62779a rsp 7fffec157440 error 4
>> > Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28507]: ALERT: 
>> > [main.c:722]: child process 28511 exited by a signal 11
>> > Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28507]: ALERT: 
>> > [main.c:725]: core was generated
>>
>> Oh my god!
>> Let me two question:
>>
>> - Are you able to determine if the problem occurs when handling an
>> INVITE or a response?
>> - Do you know if some occurs in Kamailio 1.5?
>>
>>
>>
>> --
>> Iñaki Baz Castillo
>> 
>
>



-- 
Iñaki Baz Castillo


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] possible bug with dialog module

2010-04-21 Thread Kelvin Chua

hi inaki,

unfortunately since i am not expecting any segfaults from kamailio, i have
very little
debug info, only those spurted out by syslog. not been using 1.5 for some
time now.

bad news, happened twice today. in a
span of 3 hours. seems like an inbound BYE. here is the other instance:

Apr 21 11:58:56 kamvm-1 /usr/local/sbin/kamailio[2526]: WARNING: dialog
[dlg_handlers.c:806]: unable to find dialog for BYE with route param
'e34.a5ceb3d5' [1086:1564208218]
Apr 21 11:58:56 kamvm-1 /usr/local/sbin/kamailio[2526]: ERROR: dialog
[dlg_handlers.c:218]: bad sip message or missing Contact hdr
Apr 21 11:58:56 kamvm-1 /usr/local/sbin/kamailio[2526]: ERROR: dialog
[dlg_handlers.c:350]: could not add further info to the dialog
Apr 21 11:58:56 kamvm-1 kernel: kamailio[2526]: segfault at 0088
rip 2b4a039f979a rsp 7fff0f0472c0 error 4
Apr 21 11:59:01 kamvm-1 /usr/local/sbin/kamailio[2524]: ALERT: 
[main.c:722]: child process 2526 exited by a signal 11
Apr 21 11:59:01 kamvm-1 /usr/local/sbin/kamailio[2524]: ALERT: 
[main.c:725]: core was generated


Kelvin Chua


On Wed, Apr 21, 2010 at 5:06 PM, Iñaki Baz Castillo  wrote:

> 2010/4/21 Kelvin Chua :
> > currently using kamailio 3.0 with around 1000 users.
> > Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28511]: ERROR: dialog
> > [dlg_handlers.c:218]: bad sip message or missing Contact hdr
> > Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28511]: ERROR: dialog
> > [dlg_handlers.c:350]: could not add further info to the dialog
> > Apr 21 10:19:57 kamvm-1 kernel: kamailio[28511]: segfault at
> > 0088 rip 2ab61b62779a rsp 7fffec157440 error 4
> > Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28507]: ALERT: 
> > [main.c:722]: child process 28511 exited by a signal 11
> > Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28507]: ALERT: 
> > [main.c:725]: core was generated
>
> Oh my god!
> Let me two question:
>
> - Are you able to determine if the problem occurs when handling an
> INVITE or a response?
> - Do you know if some occurs in Kamailio 1.5?
>
>
>
> --
> Iñaki Baz Castillo
> 
>
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] possible bug with dialog module

2010-04-21 Thread Iñaki Baz Castillo

2010/4/21 Kelvin Chua :
> currently using kamailio 3.0 with around 1000 users.
> Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28511]: ERROR: dialog
> [dlg_handlers.c:218]: bad sip message or missing Contact hdr
> Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28511]: ERROR: dialog
> [dlg_handlers.c:350]: could not add further info to the dialog
> Apr 21 10:19:57 kamvm-1 kernel: kamailio[28511]: segfault at
> 0088 rip 2ab61b62779a rsp 7fffec157440 error 4
> Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28507]: ALERT: 
> [main.c:722]: child process 28511 exited by a signal 11
> Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28507]: ALERT: 
> [main.c:725]: core was generated

Oh my god!
Let me two question:

- Are you able to determine if the problem occurs when handling an
INVITE or a response?
- Do you know if some occurs in Kamailio 1.5?



-- 
Iñaki Baz Castillo


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] possible bug with dialog module

2010-04-21 Thread Kelvin Chua

 currently using kamailio 3.0 with around 1000 users.

Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28511]: ERROR: dialog
[dlg_handlers.c:218]: bad sip message or missing Contact hdr
Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28511]: ERROR: dialog
[dlg_handlers.c:350]: could not add further info to the dialog
Apr 21 10:19:57 kamvm-1 kernel: kamailio[28511]: segfault at
0088 rip 2ab61b62779a rsp 7fffec157440 error 4
Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28507]: ALERT: 
[main.c:722]: child process 28511 exited by a signal 11
Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28507]: ALERT: 
[main.c:725]: core was generated


Kelvin Chua
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] possible bug with dialog module

Re: [SR-Users] possible bug with dialog module

Re: [SR-Users] possible bug with dialog module

Re: [SR-Users] possible bug with dialog module

Re: [SR-Users] possible bug with dialog module

Re: [SR-Users] possible bug with dialog module

Re: [SR-Users] possible bug with dialog module

Re: [SR-Users] possible bug with dialog module

Re: [SR-Users] possible bug with dialog module

Re: [SR-Users] possible bug with dialog module

Re: [SR-Users] possible bug with dialog module

Re: [SR-Users] possible bug with dialog module

Re: [SR-Users] possible bug with dialog module

Re: [SR-Users] possible bug with dialog module

Re: [SR-Users] possible bug with dialog module

Re: [SR-Users] possible bug with dialog module

Re: [SR-Users] possible bug with dialog module

Re: [SR-Users] possible bug with dialog module

Re: [SR-Users] possible bug with dialog module

Re: [SR-Users] possible bug with dialog module

[SR-Users] possible bug with dialog module

21 matches

Site Navigation

Mail list logo

Footer information