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

Thu Feb 6 11:53:03 CST 2014

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/1369ab77/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/1369ab77/attachment-0001.png>