Summary:ASTERISK-07443: [patch] seg fault when doing transfer and there is no "referred by" header field from transferer
Reporter:John Martin (jfp_martin)Labels:
Date Opened:2006-08-02 04:45:58Date Closed:2006-08-04 13:41:27
Versions:Frequency of
Environment:Attachments:( 0) chan_sip.c_r38730.patch
( 1) refer.cap
( 2) refer1.cap
( 3) refer1.txt
( 4) refer2.cap
( 5) refer2.txt
Description:Ast seg faults when doing transfer and there is no "referred by" header field from transferer.

Chan_sip.c is trying to do a strchr on a null pointer and seg faults.


get_refer_info() is checking the "refer to" and "referred by" message headers and sets referred_by_uri to null if there is no "referred by".
Later on when setting the referdata->referred_by a strchr is done, but if there is no "referred by" message header the strchr seg faults having been passed a pointer to null.
Patch included to fix problem.

John (AuPix)
Comments:By: Serge Vecher (serge-v) 2006-08-02 08:31:04

John: any chance of seeing a sip debug showing that "referred by" message is missing?

By: John Martin (jfp_martin) 2006-08-02 08:46:00

 I've uploaded refer.cap. I'm also looking at why we are responding to the notify's with a "bad request", but I've followed guidelines, by supplying one patch per problem...


By: John Martin (jfp_martin) 2006-08-02 08:57:32

 I'm going to open up another bug (and first check if there's one already) for the "bad request" issue raised above... the first Notify that Ast sends out has no "subscription state" and RFC 3265 section 3.2.2 states that it MUST.


By: Serge Vecher (serge-v) 2006-08-02 09:03:30

John, Olle likes to see both the packet dump and debug information produced by chan_sip parsing it. You can produce such log by following these instructions:
1) Make sure your logger.conf has the following line:
  console => notice,warning,error,debug
2) restart Asterik.
3) Enable SIP transaction logging with the following CLI commands:
set debug 4
set verbose 4
sip debug
4) Save complete console log to file and _attach_ said file to the bug.

P.S. Feel free to open a new bug report for the other problem. Don't forget to attach a SIP log there too ;)

By: John Martin (jfp_martin) 2006-08-03 04:01:14

 console log and corresponding ethereal trace file uploaded as refer1.xxx. Olle hasn't asked me for these before :-( He can replicate this behaviour with one of our AuPix videophones that he has.

Beware that the console log refers to source code lines that are not from trunk... I'm working on some new video capability stuff (that Olle an I have discussed in some detail) that isn't in trunk yet and my dialplan would struggle without the new code. The patch I uploaded is against trunk though.


By: John Martin (jfp_martin) 2006-08-03 07:44:51

Issue highlighted in (0049724) - "Notify problem" - has been opened as bug number 7651 with patch and logs.


By: Serge Vecher (serge-v) 2006-08-03 08:35:35

john: thanks. Since I don't see a segfault happening in refer1.txt -- it must be from Asterisk with your patch applied, correct? If that's the case, can you please also produce the sip debug from unpatched Asterisk to see what it does wrong?


By: John Martin (jfp_martin) 2006-08-04 05:10:05

 refer2.xxx are captured against vanilla trunk SVN38784. Debug and verbose both set to 4.

gdb "bt full" gives:

(gdb) bt full
#0  0x00be38e3 in strchr () from /lib/tls/libc.so.6
No symbol table info available.
#1  0x00999937 in get_refer_info (transferer=0x98d07a8, outgoing_req=Variable "outgoing_req" is not available.
) at chan_sip.c:8311
       r = Variable "r" is not available.

When I first submitted the patch I had a build with all the symbols available, sorry they're not in this one. Rest assured that referred_by_uri was NULL. Whoever, submits a fix for this will, I'm sure, want to do it in their own way.

I'm sorry but I can't justify any more time on this 6 line fix. <rant deleted> :-) I can have a discussion with Olle about it when he re-surfaces, there's lots we need to talk about.


By: Joshua C. Colp (jcolp) 2006-08-04 13:41:26

Fixed in trunk, thanks!