Summary: | ASTERISK-15371: Segfault while setting up T.38 fax reception | ||
Reporter: | Ben Klang (bklang) | Labels: | |
Date Opened: | 2009-12-26 16:00:32.000-0600 | Date Closed: | 2010-02-02 16:33:01.000-0600 |
Priority: | Critical | Regression? | No |
Status: | Closed/Complete | Components: | Channels/chan_sip/T.38 |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) maddison-console-bt.txt | |
Description: | I have been experimenting with T.38 fax reception via SIP. This results in an immediate crash. While I am able to capture a coredump, for whatever reason GDB and MDB do not appear to be able to give me a usable backtrace. However, Asterisk logs these message immediately before crashing: [Dec 26 21:06:25] -- Executing [fax@standard-fax:2] ReceiveFAX("SIP/broadriver-00000000", "/var/spool/fax/1261861580.0.fax,debug") in new stack [Dec 26 21:06:25] NOTICE[23097]: channel.c:2933 __ast_read: Dropping incompatible voice frame on SIP/broadriver-00000000 of format slin since our native format has changed to 0x4 (ulaw) grant*CLI> [Dec 26 21:06:25] WARNING[23097]: udptl.c:766 calculate_far_max_ifp: (no tag): Cannot calculate far_max_ifp before far_max_datagram has been set. [Dec 26 21:06:25] WARNING[23097]: udptl.c:766 calculate_far_max_ifp: (no tag): Cannot calculate far_max_ifp before far_max_datagram has been set. Next I tried forcing the max datagram in sip.conf like this: [general] t38pt_udptl=yes,maxdatagram=400 However, Asterisk still crashes with the same message. Out of curiosity, I modified main/udptl.c at line 764 in the function calculate_far_max_ifp() to force the far_max_datagram to 400: udptl->far_max_datagram = 400; Doing this prevents Asterisk from segfaulting. I wish I could share a backtrace, but so far I can't produce anything useful. I am willing to post the entire core dump if that would be helpful. | ||
Comments: | By: Leif Madsen (lmadsen) 2010-01-04 11:40:46.000-0600 The core file is only useful on the machine it was run on. Perhaps you can provide the backtrace of what you have, and maybe a developer will find something useful in it? Otherwise, it is possible this is a memory corruption issue, in which case valgrind output is what will be needed to move this forward. I think seeing the sip trace and console output just prior to the crash may be useful as well. By: Ben Klang (bklang) 2010-01-08 08:46:32.000-0600 At the next opportunity I will get a sip trace and console output. The gdb backtrace is just thousands of lines of nulls (mdb won't even give a backtrace), so I don't think it's useful at all. I'll include a paste from the next crash I generate just in case. One other possible clue has shown up during debugging: compiling with DONT_OPTIMIZE seems to prevent the crash. So now there are two workaround: force the far_max_datagram or compile with DONT_OPTIMIZE. By: Matt Addison (maddison) 2010-01-13 12:16:07.000-0600 1.6.2.0 w/ SpanDSP 0.0.5 seeing this also, sorry didn't grab a SIP trace but I do have console output and GDB backtrace (will attach). Issue goes away after setting DONT_OPTIMIZE, but it could be related to an issue I'm still seeing on this setup (getting a 503 from my switch after the originating party sends a 488 in response to the switch trying to direct reINVITE us together). Platform is x86 Debian 5.0.3 By: Grigoriy Puzankin (boroda) 2010-01-21 05:20:50.000-0600 I have the same issue. Cisco 1751 <==SIP/T.38==> Asterisk-1.6.2.0 <==SIP/T.38==> Nortel IPLDK-60 gdb shows the same output By: Ben Klang (bklang) 2010-01-21 18:56:22.000-0600 To the other commenters that have observed the same crash: do you have ignoresdpversion set on this peer? I do and I wonder if it might be related. I'm hoping to do some test late tonight with ignoresdpversion turned off, but I have other issues that prevent me from running with that configuration. By: Matt Addison (maddison) 2010-01-21 21:37:22.000-0600 Not running ignoredspversion (unless it's the default, and it doesn't sound like a default). By: Grigoriy Puzankin (boroda) 2010-01-25 01:51:41.000-0600 ignoredspversion is on for both sides. I don't remember what was wrong without it with Cisco and Nortel, but I had to turn it on. By: David Vossel (dvossel) 2010-01-25 11:20:47.000-0600 Sorry I had to mark this private. This is a security concern we are already aware of. A patch has already been made to resolve this and a new security release is in the works. We're hoping to get it out later this week. By: Digium Subversion (svnbot) 2010-02-02 16:27:26.000-0600 Repository: asterisk Revision: 244443 U trunk/channels/chan_sip.c U trunk/include/asterisk/udptl.h U trunk/main/udptl.c ------------------------------------------------------------------------ r244443 | dvossel | 2010-02-02 16:27:24 -0600 (Tue, 02 Feb 2010) | 18 lines fixes crash during T.38 negotiation caused by invalid or missing FaxMaxDatagram field AST-2010-001 (closes issue ASTERISK-15457) Reported by: krn (closes issue ASTERISK-15538) Reported by: barthpbx (closes issue ASTERISK-15371) Reported by: bklang (closes issue ASTERISK-15343) Reported by: elsto ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=244443 By: Digium Subversion (svnbot) 2010-02-02 16:29:41.000-0600 Repository: asterisk Revision: 244445 _U branches/1.6.2/ U branches/1.6.2/channels/chan_sip.c U branches/1.6.2/include/asterisk/udptl.h U branches/1.6.2/main/udptl.c ------------------------------------------------------------------------ r244445 | dvossel | 2010-02-02 16:29:38 -0600 (Tue, 02 Feb 2010) | 23 lines Merged revisions 244443 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ........ r244443 | dvossel | 2010-02-02 16:27:23 -0600 (Tue, 02 Feb 2010) | 18 lines fixes crash during T.38 negotiation caused by invalid or missing FaxMaxDatagram field AST-2010-001 (closes issue ASTERISK-15457) Reported by: krn (closes issue ASTERISK-15538) Reported by: barthpbx (closes issue ASTERISK-15371) Reported by: bklang (closes issue ASTERISK-15343) Reported by: elsto ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=244445 By: Digium Subversion (svnbot) 2010-02-02 16:31:33.000-0600 Repository: asterisk Revision: 244446 _U branches/1.6.1/ U branches/1.6.1/channels/chan_sip.c U branches/1.6.1/include/asterisk/udptl.h U branches/1.6.1/main/udptl.c ------------------------------------------------------------------------ r244446 | dvossel | 2010-02-02 16:31:30 -0600 (Tue, 02 Feb 2010) | 23 lines Merged revisions 244443 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ........ r244443 | dvossel | 2010-02-02 16:27:23 -0600 (Tue, 02 Feb 2010) | 18 lines fixes crash during T.38 negotiation caused by invalid or missing FaxMaxDatagram field AST-2010-001 (closes issue ASTERISK-15457) Reported by: krn (closes issue ASTERISK-15538) Reported by: barthpbx (closes issue ASTERISK-15371) Reported by: bklang (closes issue ASTERISK-15343) Reported by: elsto ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=244446 By: Digium Subversion (svnbot) 2010-02-02 16:33:00.000-0600 Repository: asterisk Revision: 244447 _U branches/1.6.0/ U branches/1.6.0/channels/chan_sip.c U branches/1.6.0/include/asterisk/udptl.h U branches/1.6.0/main/udptl.c ------------------------------------------------------------------------ r244447 | dvossel | 2010-02-02 16:32:56 -0600 (Tue, 02 Feb 2010) | 23 lines Merged revisions 244443 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ........ r244443 | dvossel | 2010-02-02 16:27:23 -0600 (Tue, 02 Feb 2010) | 18 lines fixes crash during T.38 negotiation caused by invalid or missing FaxMaxDatagram field AST-2010-001 (closes issue ASTERISK-15457) Reported by: krn (closes issue ASTERISK-15538) Reported by: barthpbx (closes issue ASTERISK-15371) Reported by: bklang (closes issue ASTERISK-15343) Reported by: elsto ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=244447 |