Summary:ASTERISK-16975: Segmentation Fault: #0 0x080d5dcb in ast_readaudio_callback (s=0xb2e1fa98) at file.c:762
Reporter:Jeff Hoppe (jhoppebugs)Labels:
Date Opened:2010-11-17 14:00:42.000-0600Date Closed:2011-07-27 13:07:47
Versions:Frequency of
Environment:Attachments:( 0) backtrace_2011-06-09.txt
( 1) backtrace032411.txt
( 2) backtrace10032012.txt
( 3) backtrace1117A.txt
( 4) gbb_2.txt
( 5) Thread5986.txt
( 6) workaround_ASTERISK-16975.patch
Description:Program terminated with signal 11, Segmentation fault.
#0  0x080d5dcb in ast_readaudio_callback (s=0xb2e1fa98) at file.c:762
762 if (s->owner->timingfd > -1) {
(gdb) bt
#0  0x080d5dcb in ast_readaudio_callback (s=0xb2e1fa98) at file.c:762
#1  0x080d5fdf in ast_fsread_audio (data=0xb2e1fa98) at file.c:789
#2  0x08098ca6 in __ast_read (chan=0xb46ed038, dropaudio=0) at channel.c:2784
#3  0x0809a852 in ast_read (chan=0xb46ed038) at channel.c:3181
#4  0x080958de in ast_safe_sleep_conditional (chan=0xb46ed038, ms=68, cond=0xa0a7ee <agent_cont_sleep>,
   data=0x99f1da8) at channel.c:1385
ASTERISK-1  0x00a0feb5 in login_exec (chan=0xb46ed038, data=0xb5794e78) at chan_agent.c:2236
ASTERISK-2  0x080fbcd4 in pbx_exec (c=0xb46ed038, app=0x99f0f68, data=0xb5794e78) at pbx.c:1352
ASTERISK-3  0x08103a03 in pbx_extension_helper (c=0xb46ed038, con=0x0, context=0xb46ed2ac "station",
   exten=0xb46ed2fc "7270", priority=4, label=0x0, callerid=0xb46281f0 "s3s033", action=E_SPAWN,
   found=0xb57972ec, combined_find_spawn=1) at pbx.c:3715
ASTERISK-4  0x08104f97 in ast_spawn_extension (c=0xb46ed038, context=0xb46ed2ac "station", exten=0xb46ed2fc "7270",
   priority=4, callerid=0xb46281f0 "s3s033", found=0xb57972ec, combined_find_spawn=1) at pbx.c:4186
ASTERISK-5  0x08105638 in __ast_pbx_run (c=0xb46ed038, args=0x0) at pbx.c:4280
ASTERISK-6 0x08106a91 in pbx_thread (data=0xb46ed038) at pbx.c:4567
ASTERISK-7 0x08159dca in dummy_start (data=0xb4c271e8) at utils.c:968
ASTERISK-8 0x0067073b in start_thread () from /lib/libpthread.so.0
ASTERISK-9 0x005eecfe in clone () from /lib/libc.so.6


This is actually version   I did not see any changes regarding this in the change log.  I will upgrade to this newer version but I put this here because it was identified as being fixed in in a related issue (0017686)
Comments:By: Russell Bryant (russell) 2010-12-07 11:03:00.000-0600 will be going out this week.  Can you please upgrade to that and let us know if you still see this problem?

By: Jeff Hoppe (jhoppebugs) 2010-12-07 12:13:41.000-0600

I will upgrade.  But I have been using this for months without this particular error.  I was using version and during that time.

By: Leif Madsen (lmadsen) 2011-02-08 13:19:07.000-0600


By: Jeff Hoppe (jhoppebugs) 2011-02-08 13:22:08.000-0600

I have upgraded and still get this error occassionally.  Everytime I get the error a new sub version of asterisk has been out.  Therefore, I try the new version see if it fixes the issue.  Don't know what to do at this point.

By: Jeff Hoppe (jhoppebugs) 2011-03-24 14:40:45

Is there any other information I can get you to help facilitate the correcting of this error we are getting?  I have uploaded a recent crashes backtrace file in case it helps.

By: Jeff Hoppe (jhoppebugs) 2011-03-24 14:50:45

Thread5986.txt will show the full log of the thread that errored on Backtrace032411.txt.   With other logs of our system, we have concluded that this is erroring when a "beep" gets played to an agent.

The last line in this thread is the same time that the crash happens because the next full log line 5 seconds later, shows the restart processing.

I do stress that this only has been happening once a month, and we are taking many calls without this happpening.

By: Kristijan Vrban (vrban) 2011-06-10 04:37:59.112-0500

i also had two crash in file.c in in the "if (s->owner->timingfd > -1)" line.
see backtrace_2011-06-09.txt (asterisk 1.4.42) See the print *s in the backtrace.
s->owner is NULL. So then it crash with "if (s->owner->timingfd > -1)". But why
can be s->owner be NULL? My assumption is, perhaps it happen when masquerade two
channels i case of a transfer.

By: Kristijan Vrban (vrban) 2011-06-10 06:42:40.950-0500

Hey Jeff, please test workaround_ASTERISK-16975.patch It should prevent this crash.
But is not a solution for the main issue. and if it prevent the crash, the price is,
that it does not playback the soundfile.

By: Kristijan Vrban (vrban) 2011-06-14 03:37:28.753-0500

next core at line {noformat}if (s->owner->timingfd > -1){noformat} (this maschine was without the patch i made) especially see the output of print *s and print *chan at the end of the file gdb_2.txt

By: Kristijan Vrban (vrban) 2011-06-14 04:04:41.491-0500

also this core in gdb_2.txt happened when the call was transfered / a SIP REFER was done. So it definite an issue when chan masquerade is done, and in the wrong moment the soundfile start while the masquerade is in progress. (my assumption)

By: Russell Bryant (russell) 2011-07-27 13:07:39.768-0500

Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.4 and 1.6.x branches has ended. For continued maintenance support please move to the 1.8 branch which is a long term support (LTS) branch. For more information about branch support, please see https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions

If this is still an issue, please open a new issue so it can be re-triaged appropriately. Thanks!

By: Jeff Hoppe (jhoppebugs) 2012-10-03 15:51:53.230-0500

Kristijan, the next time I got this error I was going to apply the patch.  I never got the error before I upgraded to Asterisk 10.  After running asterisk 10 for 8 months I just got the same or similar error.  See attachments for the back trace.

Can you create a patch that will work in Asterisk 10  (10.6 is my current version, I don't see any fixes to this issue in the 10.8 change log).


By: Jeff Hoppe (jhoppebugs) 2012-10-03 15:53:23.924-0500

Need a patch to correct this error on Asterisk 10, like the one used to correct it on 1.6.2

By: Jeff Hoppe (jhoppebugs) 2012-10-03 16:21:11.040-0500

Kristijan,  I looked at the patch and I believe I can make this change myself.   I can add those same lines to the ast_readaudio_callback for Asterisk 10.  
So your thinking that every function/method that calls this ast_readaudio_callback will accept the returned -1 and handle it just as if the ast_readaudio_callback returned one of its unsuccessful messages when it doesn't err?