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
Dň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="" out>) at
res_fax.c:1932
#4 0x0000000000530fdd in pbx_exec
(c=c@entry=0x7fadc4548c18, app=app@entry=0x2ddca60,
data=""
"/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=""
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="" at pbx.c:6843
#9 0x0000000000587c5a in dummy_start (data=""
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
|
