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. |