Summary:ASTERISK-09042: Asterisk segfaults upon receipt of a certain SIP packet (SIP Response code 0)
Reporter:Filip Dimitrov (qwerty1979)Labels:
Date Opened:2007-03-18 07:59:41Date Closed:2007-06-30 09:20:08
Versions:Frequency of
Environment:Attachments:( 0) bt-full-trunk-r59090.txt
( 1) bt-trunk-r59090.txt
( 2) crashing-sip-packet.txt
( 3) crashing-sip-packet-trunk-r59090-masked.txt
( 4) sip-debug-trunk-r59090-masked.txt
( 5) threads-trunk-r59090.txt
( 6) verbose-1.0.7-BRIstuffed-0.2.0-RC7k-masked.txt
( 7) verbose-trunk-r58995-crash-masked.txt
Description:Asterisk segfaults upon receipt of a certain SIP reply from the remote system (SIP Response code 0).

I am originating a call (by a means of a .call file) from my asterisk to a mobile phone thru a service provider. The call goes thru and the mobile phone rings. When i reject the call on the mobile phone Asterisk segfaults.

I've used a packet sniffer and noticed that the packet that seems to crash asterisk is a SIP packet from the remote equipment containing SIP Response code 0.


Asterisk-trunk-r58995 (the lastest i think)
Linux Debian sarge (stable)
Kernel - 2.6.8-2-686
the remote equipment seems to be a Vega 400 - connecting thru SIP

i've also tested this on the asterisk 1.4.1 tarball and am able to reproduce the bug

i've also tested this on the asterisk 1.0.7 version that is in the stable debian tree and it does not crash but only produces a warning:
NOTICE: chan_sip.c:6971 handle_response: Don't know anything about a 0  response from SIP/orbi-517d
Comments:By: Olle Johansson (oej) 2007-03-18 15:33:34

When reporting a crash, we do need a backtrace of the core file. Can you provide us with that to make sure we know where Asterisk crashes? See the bug guidelines for instructions.

By: Olle Johansson (oej) 2007-03-18 15:38:30

Patch committed to Asterisk 1.4 svn, rev 59037 and svn trunk.

Please test and confirm in this issue report as soon as possible. Thank you for your cooperation in reporting and testing this issue.


By: Filip Dimitrov (qwerty1979) 2007-03-21 18:35:52

Sorry it took me so long.

- the bug submission guidelines:
there are two pages describing submission guidelines, but none of them actually have any detailed instruction on how to provide a SIP debug or backtrace. While i've been able to find out how to get the debug of the SIP conversation by reading other bug reports, I have just a vague idea what a backtrace/core file is. It would be good to have detailed instructions on the bug submission page as to allow non-programmers to be able to collect all the information needed to help with reporting bugs.

- the patch:
I've tested with Asterisk SVN-trunk-r59090 and the bug is still there...

I'd like to provide a backtrace, but have no idea how to do it.

Thanks for bearing with me ;)

By: Clod Patry (junky) 2007-03-21 23:30:58

qwerty: Please see the file doc/backtrace.txt

By: Serge Vecher (serge-v) 2007-03-22 08:21:50

in addition to the backtrace, please produce a sip debug log as per:
1) Prepare test environment (reduce the amount of unrelated traffic on the server);
2) Make sure your logger.conf has the following line:
  console => notice,warning,error,debug
3) restart Asterisk with the following command:
  'asterisk -Tvvvvvdddddngc | tee /tmp/verbosedebug.txt'
4) Enable SIP transaction logging with the following CLI commands (1.4/trunk commands in parenthesis):
set debug 4 (core set debug 4)
set verbose 4 (core set verbose 4)
sip debug (sip set debug)
5) Reproduce the problem
6) Trim startup information and attach verbosedebug.txt to the issue.

By: Filip Dimitrov (qwerty1979) 2007-03-22 15:36:56

junky & serge-v: Thanks for the pointers ;) I still think this bits of info belong to the bug guidelines page :)

I did a new SIP debug log and also a backtrace (hope I did it right).

Hope that helps in nailing the bug down ;)

By: Serge Vecher (serge-v) 2007-03-22 15:42:25

the problematic packet (crashing-sip-packet-trunk-r59090-masked.txt) does not seem to be present in sip-debug-trunk-r59090-masked.txt

By: Filip Dimitrov (qwerty1979) 2007-03-22 17:02:31

This is correct. After looking at the SIP debug log and not seeing anything out of the ordinary i used a packet sniffer and find out that the asterisk is segfaulting upon the receipt of that one last packet that doesn't even show in the debug log. Or so it seems ;)

By: Clod Patry (junky) 2007-03-22 22:04:08

Make sure you have a non-optmized bt.
type make menuselect, select Compiler Flags
and check DONT_OPTIMIZE.

then make && make install and reproduce your test.

Also, include all the output, not just a part.

By: Filip Dimitrov (qwerty1979) 2007-03-23 04:47:33

I did select DONT_OPTIMIZE in menuconfig and then compiled asterisk.

as per doc/backtrace.txt:

"Now, just create an output.txt file and dump your "bt full"
(and/or "bt") ALONG WITH "thread apply all bt" into it."

which is what i did. I did split it in 3 files tho.

By: Serge Vecher (serge-v) 2007-03-23 12:12:54

I bet 1.4 branch is affected too ...

By: Joshua C. Colp (jcolp) 2007-03-23 12:26:33

I've tested all SIP packets on this bug against the latest version of things, and they don't crash. The last backtrace listed is not useful at all... but I suspect that this new bug requires an active dialog to be up so you can't just exploit it by sending the packet.

By: David Svanlund (svanlund) 2007-03-23 19:57:20

I am able to reproduce this bug - some really nasty stuff. Tested against 1.2.17 as well as latest svn. The sensitive details will be provided to a core asterisk developer or equal, as soon as I can get someone to look at it.

By: Joshua C. Colp (jcolp) 2007-03-30 15:22:34

All brought up issues have been solved in this bug as of latest SVN of everything.