[prev in list] [next in list] [prev in thread] [next in thread]
List: asterisk-dev
Subject: Re: [asterisk-dev] res_fax_spandsp segfaults during fax detection - FIXED?
From: Michal_Rybárik <michal () rybarik ! sk>
Date: 2014-02-06 20:26:05
Message-ID: 52F3EFDD.2040804 () rybarik ! sk
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@entry=0x7fadc4548c18,
>> details=details@entry=0x7fad50602c28,
>> reserved=reserved@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@entry=0x7fadc4548c18,
>> app=app@entry=0x2ddca60, data=data@entry=0x7fad838b6cd0
>> "/tmp/morpheus-1391681512.850.tiff") at pbx.c:1622
>> #5 0x000000000053656f in pbx_extension_helper
>> (c=c@entry=0x7fadc4548c18, context=<optimized out>,
>> exten=exten@entry=0x7fadc4549ab8 "0123489251",
>> priority=priority@entry=6, label=label@entry=0x0,
>> callerid=callerid@entry=0x7fadc44757b0 "0126413300",
>> action=action@entry=E_SPAWN, found=found@entry=0x7fad838bad60,
>> combined_find_spawn=combined_find_spawn@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@entry=0x7fadc4548c18, args=args@entry=0x0) at
>> pbx.c:6513
>> #8 0x0000000000541c0b in pbx_thread (data=data@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
>>>
>>
>
[Attachment #5 (multipart/related)]
[Attachment #7 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Hi Jaco,<br>
<br>
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.<br>
<br>
Regards,<br>
Michal Rybarik<br>
<br>
On 02/06/2014 06:53 PM, Michal Rybarik wrote:
<blockquote cite="mid:52F3CBFF.7000707@rybarik.sk" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Hi Jaco,<br>
<br>
if I understand correctly, your segfault did not happen during in
T38gateway, but while receiving fax to tiff file (ReceiveFax), am
I right?<br>
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.<br>
<pre class="moz-signature" cols="72">--
Regards,
Michal Rybarik</pre>
<br>
<br>
Dňa 6. 2. 2014 12:07, Jaco Kroon wrote / napísal(a):
<blockquote cite="mid:52F36CDD.5060608@uls.co.za" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix"><font face="Helvetica, Arial,
sans-serif">Hi All,<br>
<br>
Could this backtrace possibly be related?<br>
<br>
#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<br>
#1 0x00007fae11c22c7d in t38_core_rx_ifp_packet
(s=0x7fae54c698a8, buf=0x7fae54c8475b "\002", len=1,
seq_no=<optimized out>) at t38_core.c:459<br>
#2 0x00007fae50ea96c5 in generic_fax_exec
(chan=chan@entry=0x7fadc4548c18,
details=details@entry=0x7fad50602c28,
reserved=reserved@entry=0x7fad50155478, token=<optimized
out>) at res_fax.c:1498<br>
#3 0x00007fae50eaea9e in receivefax_exec
(chan=0x7fadc4548c18, data=<optimized out>) at
res_fax.c:1932<br>
#4 0x0000000000530fdd in pbx_exec
(c=c@entry=0x7fadc4548c18, app=app@entry=0x2ddca60,
data=data@entry=0x7fad838b6cd0
"/tmp/morpheus-1391681512.850.tiff") at pbx.c:1622<br>
#5 0x000000000053656f in pbx_extension_helper
(c=c@entry=0x7fadc4548c18, context=<optimized out>,
exten=exten@entry=0x7fadc4549ab8 "0123489251",
priority=priority@entry=6, label=label@entry=0x0,
callerid=callerid@entry=0x7fadc44757b0 "0126413300",
action=action@entry=E_SPAWN,
found=found@entry=0x7fad838bad60, <br>
combined_find_spawn=combined_find_spawn@entry=1,
con=0x0) at pbx.c:4922<br>
#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<br>
#7 __ast_pbx_run (c=c@entry=0x7fadc4548c18,
args=args@entry=0x0) at pbx.c:6513<br>
#8 0x0000000000541c0b in pbx_thread
(data=data@entry=0x7fadc4548c18) at pbx.c:6843<br>
#9 0x0000000000587c5a in dummy_start (data=<optimized
out>) at utils.c:1162<br>
#10 0x00007fae530f2f3a in start_thread (arg=0x7fad838bb700)
at pthread_create.c:308<br>
#11 0x00007fae54754dad in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:113<br>
<br>
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.<br>
<br>
</font>
<div class="moz-signature">Kind Regards,<br>
Jaco Kroon<br>
<img src="cid:part1.05020808.02090304@rybarik.sk"
usemap="#Map" style="color: white;" height="100"
width="530" border="0"> <map name="Map" id="Map">
<area shape="rect" coords="441,19,460,36"
href="https://www.facebook.com/ultimatelinuxsolutions">
<area shape="rect" coords="441,39,458,57"
href="http://news.uls.co.za/">
<area shape="rect" coords="354,62,461,73"
href="http://www.uls.co.za/">
</map>
</div>
On 01/02/2014 06:49, Michal Rybárik wrote:<br>
</div>
<blockquote cite="mid:52EC7CE6.7000208@rybarik.sk" type="cite">Hello
Pavel, <br>
<br>
On 01/31/2014 07:59 AM, Pavel Troller wrote: <br>
<blockquote type="cite">
<blockquote type="cite">This code will translate non-slinear
frames to slinear, just before they <br>
are sent to libspandsp for v21detection. With this patch
applied, v21 <br>
detection is done also for RTP (SIP) alaw/ulaw frames, so
maybe SIP/G711 <br>
<-> SIP/T38 gateway will work too. I tested
DAHDI<-> SIP/T38, gateway <br>
works both ways, voice calls too. Is it better now? :o) <br>
</blockquote>
I fully understand the code, but I'm not trained enough in
the Asterisk <br>
internals to respond to questions, which immediately
appeared in my head: <br>
1) In the original code, the result from
fax_gateway_detect_v21() is returned. <br>
Now, you are returning the original frame. I quickly looked
at the above <br>
routine and it in turn calls fax_gateway_request_t38() and
returns its <br>
result (but not always), and in the
fax_gateway_request_t38() function <br>
they are also returning different things according to
results of the <br>
program flow. So, is it really safe to do this ? Are you
sure, that the <br>
real result is really unneccessary ? <br>
2) Are you sure, that ast_translate() will always allocate a
new buffer for <br>
tmpframe ? Is it written somewhere ? Isn't it possible that
it will just <br>
reallocate the buffer for the original frame to increase its
size and return <br>
its pointer, so by doing ast_frfree() you would just
deallocate the same <br>
buffer, thus making big troubles ? You would find it by
checking that <br>
tmpframe != f... <br>
As you can see, I'm very careful, or maybe even a bit
conservative, with <br>
patching things, unless I really DEEPLY understand, how they
are going... <br>
So, I believe, that you really studied the code enough to be
sure, that <br>
you can really clear my doubts by your deep knowledge... I
didn't have time <br>
to study the code to such extent... <br>
</blockquote>
<br>
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 <br>
<br>
Regards, <br>
Michal Rybarik <br>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>
[Attachment #8 (image/png)]
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic