Summary:	ASTERISK-25464: Segfault with T.38 protocol and ReceiveFax Application
Reporter:	Peter Pfannenschmid (Binarus)	Labels:
Date Opened:	2015-10-13 15:03:27	Date Closed:	2015-10-19 05:58:56
Priority:	Critical	Regression?
Status:	Closed/Complete	Components:	Resources/res_fax_spandsp
Versions:	13.5.0	Frequency of Occurrence	Constant
Related Issues:
Environment:	Debian Wheezy x64 stock distribution (kernel 3.2.0) with following exceptions (all compiled myself, no patches or alterations): Asterisk 13.5.0, PJSIP 2.4.5, SpanDSP 0.0.6	Attachments:	( 0) gdb.txt
Description:	Sending a fax from a T.38 capable endpoint to an extension which just should do ReceiveFax (i.e. store the fax on HDD for testing purposes); segfault occurs even before the tiff file is created.
Comments:	By: Asterisk Team (asteriskteam) 2015-10-13 15:03:28.473-0500 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Peter Pfannenschmid (Binarus) 2015-10-13 15:05:07.062-0500 Just attached the gdb log file with "bt", "bt full" and "thread apply all bt" results. By: Rusty Newton (rnewton) 2015-10-14 18:03:10.239-0500 Please note that res_fax_spandsp is extended support so response time will reflect that while we are consumed with core supported modules. I've had a developer look over it quickly to assist with triage. Please provide the following: * a debug log captured right up until the crash.[1] * a new backtrace that correlates with the log * the new backtrace should be captured with DONT_OPTIMIZE and BETTER_BACKTRACES compiled. * compile libspandsp with debug symbols as we are missing some information on the last frame. * If the crash looks identical please print f and p from frame #2 [1]: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information By: Peter Pfannenschmid (Binarus) 2015-10-19 02:25:10.956-0500 In the meantime, I have upgraded to Asterisk 13.6.0. The crash does not happen any more with that version, so I suggest to close the bug.