[Home]

Summary:ASTERISK-17336: Segfault when transferring call
Reporter:Alastair Battrick (ajbattrick)Labels:
Date Opened:2011-02-02 07:16:11.000-0600Date Closed:2012-09-05 16:39:26
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) asterisk_backtrace-11022011_133100.txt
( 1) gdb.txt
( 2) sip_setopt_bt_2.txt
( 3) sip_setopt_bt.txt
Description:Asterisk crashes with <ZOMBIE> in the log.

We have a SIP trunk, with approx 25 SIP users and a couple of IAX users. The log shows it happening just after musiconhold comes off, but that could be a coincidence.

Running on Centos 5.5
Linux version 2.6.18-194.26.1.el5

gdb backtrace attached

****** ADDITIONAL INFORMATION ******

[Feb  2 12:38:01] VERBOSE[8940] chan_sip.c:   == Extension Changed 514[ext-local] new state InUse for Notify User 514
[Feb  2 12:38:01] VERBOSE[8940] chan_sip.c:   == Extension Changed 514[ext-local] new state InUse for Notify User 256
[Feb  2 12:38:01] VERBOSE[8940] chan_sip.c:   == Extension Changed 514[ext-local] new state InUse for Notify User 260 (queued)
[Feb  2 12:38:01] VERBOSE[8940] chan_sip.c:   == Extension Changed 514[ext-local] new state InUse for Notify User 512
[Feb  2 12:38:07] VERBOSE[12371] res_musiconhold.c:     -- Started music on hold, class 'default', on SIP/514-000002b6
[Feb  2 12:38:07] VERBOSE[8964] res_musiconhold.c:     -- Stopped music on hold on SIP/77.240.48.214:5061-000002ac
[Feb  2 12:38:07] VERBOSE[12371] pbx.c:     -- Executing [h@macro-dial-one:1] Macro("SIP/259-000002b5", "hangupcall,") in new stack
[Feb  2 12:38:07] VERBOSE[12371] pbx.c:     -- Executing [s@macro-hangupcall:1] GotoIf("SIP/259-000002b5", "1?skiprg") in new stack
[Feb  2 12:38:07] VERBOSE[12371] pbx.c:     -- Goto (macro-hangupcall,s,4)
[Feb  2 12:38:07] VERBOSE[12371] pbx.c:     -- Executing [s@macro-hangupcall:4] GotoIf("SIP/259-000002b5", "1?skipblkvm") in new stack
[Feb  2 12:38:07] VERBOSE[12371] pbx.c:     -- Goto (macro-hangupcall,s,7)
[Feb  2 12:38:07] VERBOSE[12371] pbx.c:     -- Executing [s@macro-hangupcall:7] GotoIf("SIP/259-000002b5", "1?theend") in new stack
[Feb  2 12:38:07] VERBOSE[12371] pbx.c:     -- Goto (macro-hangupcall,s,9)
[Feb  2 12:38:07] VERBOSE[12371] pbx.c:     -- Executing [s@macro-hangupcall:9] Hangup("SIP/259-000002b5", "") in new stack
[Feb  2 12:38:07] VERBOSE[12371] app_macro.c:   == Spawn extension (macro-hangupcall, s, 9) exited non-zero on 'SIP/259-000002b5' in macro 'hangupcall'
[Feb  2 12:38:07] VERBOSE[12371] features.c:   == Spawn extension (macro-dial-one, h, 1) exited non-zero on 'SIP/259-000002b5'
[Feb  2 12:38:07] VERBOSE[12371] res_musiconhold.c:     -- Stopped music on hold on SIP/259-000002ad<ZOMBIE>
[Feb  2 12:38:15] VERBOSE[12398] config.c:   == Parsing '/etc/asterisk/asterisk.conf': [Feb  2 12:38:15] VERBOSE[12398] config.c:   == Found
[Feb  2 12:38:16] VERBOSE[12398] manager.c:   == Manager registered action DataGet
[Feb  2 12:38:16] VERBOSE[12398] loader.c:  Asterisk Dynamic Loader Starting:
Comments:By: Alastair Battrick (ajbattrick) 2011-02-02 07:18:05.000-0600

I should mention that Asterisk is configured using FreePBX 2.9
By: Michael L. Young (elguero) 2011-02-02 10:36:14.000-0600

I just uploaded a bt that is unoptimized.  It would appear to be crashing in the same place as ajbattrick bt shows.

Centos 5.5, latest kernel.

Vanilla Asterisk 1.8.2.1


By: Sébastien Couture (sysreq) 2011-02-11 13:24:53.000-0600

Does it crash or does it just hang, ie. stops responding to SIP requests? Because I seem to be having the same problem: a "stopped music on hold.." is the last thing seen in the log before Asterisk stops responding to any call requests. We have to kill the process and start it again.

I'll attach a backtrace of the running process.
By: Sébastien Couture (sysreq) 2011-02-11 13:26:04.000-0600

Oh, I didn't mention.. I'm using Asterisk 1.6.2 SVN rev. 306973 with Addons 1.6.2.3.
By: Michael L. Young (elguero) 2011-02-11 14:14:22.000-0600

In the case of the bt that I uploaded, it just crashes and it appears to be triggered by a transfer.

In looking at your bt, it appears to be a different issue from the other two backtraces.
By: Michael L. Young (elguero) 2011-02-16 09:01:32.000-0600

After going a couple weeks of no segfaults, there has been a segfault once a day for the past three days.
By: Mark Murawski (kobaz) 2011-07-18 07:30:32.062-0500

Try the patch in ASTERISK-17909
By: David Vossel (dvossel) 2011-07-20 16:13:04.393-0500

This is likely fixed in the 1.8.5 release.
By: Matt Jordan (mjordan) 2012-09-05 08:16:00.192-0500

Can you confirm if this is fixed in later versions of 1.8?
By: Alastair Battrick (ajbattrick) 2012-09-05 16:27:33.357-0500

The fault was too critical so I had to downgrade to 1.6.2 (I think) soon after reporting this bug. Earlier this year I upgraded to 1.8.6 without any issues so far.
By: Matt Jordan (mjordan) 2012-09-05 16:39:10.576-0500

If you're on 1.8.6 and haven't had this issue re-occur, then it sounds like this issue was a duplicate of ASTERISK-17909 and was therefore fixed in the 1.8.5 release.  If you run into this issue again, please feel free to contact a bug marshal in #asterisk-bugs or on the mailing list and we'll reopen this issue.  Thanks!