[asterisk-dev] res_fax_spandsp segfaults during fax detection - FIXED?

Thu Feb 6 14:26:05 CST 2014

Hi Jaco,

I reviewed spandsp sources at the places where your segfaults happened, 
and this is very different situation than mine. But I see that span_log 
function (spandsp logging) is called frequently from this code, you 
should find some more information in spandsp log probably, to discover 
what happened before your segfault.

Regards,
Michal Rybarik

On 02/06/2014 06:53 PM, Michal Rybarik wrote:
> Hi Jaco,
>
> if I understand correctly, your segfault did not happen during in 
> T38gateway, but while receiving fax to tiff file (ReceiveFax), am I right?
> I haven't checked neither patched this (because my Asterisks are only 
> relaying faxes, not terminating/originating to/from tiff file), but if 
> your segfault happen when data are passed to libspandsp, it should be 
> the same situation as mine was. Code in res_fax allows 
> slinear/alaw/ulaw frames to be passed to res_fax_spandsp and then to 
> libspandsp, but libspandsp accepts only slinear. When ulaw/alaw frames 
> are passed here, bad things can happen.
> -- 
> Regards,
> Michal Rybarik
>
>
> Dn(a 6. 2. 2014 12:07, Jaco Kroon  wrote / napísal(a):
>> Hi All,
>>
>> Could this backtrace possibly be related?
>>
>> #0  process_rx_data (t=0x7fae54c698a8, user_data=0x2, data_type=1, 
>> field_type=<optimized out>, buf=0x7fae11c58cda "cng", len=0) at 
>> t38_terminal.c:314
>> #1  0x00007fae11c22c7d in t38_core_rx_ifp_packet (s=0x7fae54c698a8, 
>> buf=0x7fae54c8475b "\002", len=1, seq_no=<optimized out>) at 
>> t38_core.c:459
>> #2  0x00007fae50ea96c5 in generic_fax_exec 
>> (chan=chan at entry=0x7fadc4548c18, 
>> details=details at entry=0x7fad50602c28, 
>> reserved=reserved at entry=0x7fad50155478, token=<optimized out>) at 
>> res_fax.c:1498
>> #3  0x00007fae50eaea9e in receivefax_exec (chan=0x7fadc4548c18, 
>> data=<optimized out>) at res_fax.c:1932
>> #4  0x0000000000530fdd in pbx_exec (c=c at entry=0x7fadc4548c18, 
>> app=app at entry=0x2ddca60, data=data at entry=0x7fad838b6cd0 
>> "/tmp/morpheus-1391681512.850.tiff") at pbx.c:1622
>> #5  0x000000000053656f in pbx_extension_helper 
>> (c=c at entry=0x7fadc4548c18, context=<optimized out>, 
>> exten=exten at entry=0x7fadc4549ab8 "0123489251", 
>> priority=priority at entry=6, label=label at entry=0x0, 
>> callerid=callerid at entry=0x7fadc44757b0 "0126413300", 
>> action=action at entry=E_SPAWN, found=found at entry=0x7fad838bad60,
>>     combined_find_spawn=combined_find_spawn at entry=1, con=0x0) at 
>> pbx.c:4922
>> #6  0x00000000005404a4 in ast_spawn_extension (found=0x7fad838bad60, 
>> callerid=0x7fadc44757b0 "0126413300", priority=6, 
>> exten=0x7fadc4549ab8 "0123489251", context=<optimized out>, 
>> c=0x7fadc4548c18, combined_find_spawn=<optimized out>) at pbx.c:6038
>> #7  __ast_pbx_run (c=c at entry=0x7fadc4548c18, args=args at entry=0x0) at 
>> pbx.c:6513
>> #8  0x0000000000541c0b in pbx_thread (data=data at entry=0x7fadc4548c18) 
>> at pbx.c:6843
>> #9  0x0000000000587c5a in dummy_start (data=<optimized out>) at 
>> utils.c:1162
>> #10 0x00007fae530f2f3a in start_thread (arg=0x7fad838bb700) at 
>> pthread_create.c:308
>> #11 0x00007fae54754dad in clone () at 
>> ../sysdeps/unix/sysv/linux/x86_64/clone.S:113
>>
>> Had about 11 of those this morning on asterisk 11.7.0.  Codec's 
>> that's allowed on SIP though is g729 and gsm only, so no ulaw/alaw 
>> allowed.  Actually, just double checked, ulaw/alaw is (was now) 
>> allowed, so someone is possibly trying to run in bypass mode, 
>> resulting in the t38 gateway instead of t38 pass through.  I 
>> downgraded to 11.6.0 and hadn't had a crash since but I opted to 
>> disable ulaw+alaw in any case, just to be on the safer side.
>>
>> Kind Regards,
>> Jaco Kroon
>> On 01/02/2014 06:49, Michal Rybárik wrote:
>>> Hello Pavel,
>>>
>>> On 01/31/2014 07:59 AM, Pavel Troller wrote:
>>>>> This code will translate non-slinear frames to slinear, just 
>>>>> before they
>>>>> are sent to libspandsp for v21detection. With this patch applied, v21
>>>>> detection is done also for RTP (SIP) alaw/ulaw frames, so maybe 
>>>>> SIP/G711
>>>>> <->  SIP/T38 gateway will work too. I tested DAHDI<->  SIP/T38, 
>>>>> gateway
>>>>> works both ways, voice calls too. Is it better now? :o)
>>>> I fully understand the code, but I'm not trained enough in the 
>>>> Asterisk
>>>> internals to respond to questions, which immediately appeared in my 
>>>> head:
>>>> 1) In the original code, the result from fax_gateway_detect_v21() 
>>>> is returned.
>>>> Now, you are returning the original frame. I quickly looked at the 
>>>> above
>>>> routine and it in turn calls fax_gateway_request_t38() and returns its
>>>> result (but not always), and in the fax_gateway_request_t38() function
>>>> they are also returning different things according to results of the
>>>> program flow. So, is it really safe to do this ? Are you sure, that 
>>>> the
>>>> real result is really unneccessary ?
>>>> 2) Are you sure, that ast_translate() will always allocate a new 
>>>> buffer for
>>>> tmpframe ? Is it written somewhere ? Isn't it possible that it will 
>>>> just
>>>> reallocate the buffer for the original frame to increase its size 
>>>> and return
>>>> its pointer, so by doing ast_frfree() you would just deallocate the 
>>>> same
>>>> buffer, thus making big troubles ? You would find it by checking that
>>>> tmpframe != f...
>>>>    As you can see, I'm very careful, or maybe even a bit 
>>>> conservative, with
>>>> patching things, unless I really DEEPLY understand, how they are 
>>>> going...
>>>> So, I believe, that you really studied the code enough to be sure, 
>>>> that
>>>> you can really clear my doubts by your deep knowledge... I didn't 
>>>> have time
>>>> to study the code to such extent...
>>>
>>> Answering these questions is not easy for me too, there are some 
>>> parts of res_fax code which I don't fully understand. So I rather 
>>> reworked the patch and moved it to another place, where 
>>> functionality is easier to understand, and when it shouldn't harm 
>>> anything. I uploaded diff to JIRA  - 
>>> https://issues.asterisk.org/jira/browse/ASTERISK-20149
>>>
>>> Regards,
>>> Michal Rybarik
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140206/359612ce/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 26699 bytes
Desc: not available
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140206/359612ce/attachment-0001.png>