Hello Michal,
I'm afraid that I can't help, but I'm observing exactly the same crashes
as you are. They are very rare here, about one crash per 2 - 3 millions of
successful calls (but of course most of the calls are voice ones), so
debugging is very problematic. However, it's crashing exactly on the same
place in spandsp code.
Please note that not only mallocd_hdr_len is changing, but primarily
datalen is too! If you subtract those malloc_hdr_len values (722 - 562),
you will get 160, which is exactly the difference between the datalen
values. I think that primary cause is the different datalen, and the size
of allocated memory just reflects this. However, another value, samples,
is the same in both cases: 160. Isn't it suspicious ? Why I need twice as
much data length for the same number of samples ? Oh, possibly because they
are in linear format, thus 16 bits wide (because conversion alaw2lin
produces 13bit samples), while in the second case they are in some other
format (see src=alawtolin in the "good" case and src=RTP in the "wrong"
one). But which one is it ? Native a-law ? Possibly... But it could be
also u-law ? How the routine gets the actual codec, in which the samples
are ?
So, we digged at least some information about the crash, but in my case,
my theoretical background of the V.21 detection is almost none, so I can't
find more. Maybe this is enough for some more skilled person, like the
res_fax author, to judge, what can be a primary cause of this problem ?
With regards,
Pavel
Hello,
I have problem with random Asterisk segfaults on the machine, which I use
as T.38 gateway between DAHDI and SIP. I would like to kindly ask somebody
to take a look at it, and help me to find what's wrong... Asterisk is
version 11 from SVN, r382022 (I'm using this because of other dependencies
- I compared relevant sources to current v11 SVN and they are almost
unchanged).
Segfault happens on voice calls, during detection of fax preamble.
Segfaults happens randomly - sometimes there is segfault after 50.000
calls, sometimes after 5 calls. In coredumps I see, that segfault happens
in libspandsp2.so (version 0.06-pre21, and latest snapshot too).
I asked Steve Underwood (spandsp author) about this, and he pointed me to
the application itself - probably there is something wrong with "amp"
(pointer to the audio samples data), because this pointer is first time
used in function fsk_rx(), where segfault happens. So I looked deeper into
this, and added some debug info into the res_fax_spandsp.c source, into
function spandsp_v21_detect(), just before calling modem_connect_tones_rx()
(the function, which calls fsk_rx() later). Now I see the contents of frame
which caused segfault, and also the "amp" pointer (in asterisk it is
f->data.ptr), but I'm not sure what's wrong with it.
[Jan 27 14:00:22] VERBOSE[30694][C-000006cb] app_dial.c: -- Called
DAHDI/G2/123456789
[Jan 27 14:00:27] VERBOSE[30694][C-000006cb] app_dial.c: -- DAHDI/57-1
is proceeding passing it to SIP/mypbx-00000729
[Jan 27 14:00:27] VERBOSE[30694][C-000006cb] app_dial.c: -- DAHDI/57-1
is ringing
[Jan 27 14:00:32] VERBOSE[30694][C-000006cb] app_dial.c: -- DAHDI/57-1
answered SIP/mypbx-00000729
[Jan 27 14:00:32] NOTICE[30694][C-000006cb] res_fax_spandsp.c: frame={
frametype=2, datalen=320, samples=160, mallocd=1, mallocd_hdr_len=722,
offset=64, src=alawtolin, flags=0, ts=0, len=0, seqno=0,
data.ptr=0xb50c91b8 }
[Jan 27 14:00:32] NOTICE[30694][C-000006cb] res_fax_spandsp.c: frame={
frametype=2, datalen=160, samples=160, mallocd=1, mallocd_hdr_len=562,
offset=64, src=RTP, flags=1, ts=9140, len=20, seqno=1489,
data.ptr=0xb4ef4f30 }
(... segfault now ...)
Core was generated by `/usr/sbin/asterisk -f -p -U asterisk -vvvg -c'.
Program terminated with signal 11, Segmentation fault.
#0 fsk_rx (s=0x83ea7e8, amp=0xb4ef4f30, len=160) at fsk.c:381
381 s->window[j][buf_ptr].re = (ph.re*amp[i])>>
s->scaling_shift;
Last line from Asterisk log shows contents of ast_frame struct *f, which
caused segfault. I see that segfualt was caused by first frame, which
arrived from DAHDI (src=RTP) and which was passed to spands_v21_detect(),
and then to modem_connect_tones_rx(), and then fsk_rx().
Only one unusual thing, which I see on this frame, is that
f->mallocd_hdr_len=562. Many other frames have this set to 722 (if
f->mallocd==1) or to 0 (if f->mallocd==0). But in a few cases, I saw frames
with malloc_hdr_len set to different values, and these frames didn't cause
segfault.
Is there anybody who can help?
Many thanks..
--
Michal Rybarik
--
_____________________________________________________________________
-- 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
