[Home]

Summary:ASTERISK-11424: Asterisk crash when I park a call
Reporter:Joel Vandal (jvandal)Labels:
Date Opened:2008-02-12 12:04:00.000-0600Date Closed:2008-09-12 14:00:57
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Resources/res_features
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) bt11979parkblindxferjune12_2008.txt
( 1) bt-20080821.txt
( 2) btfull11979parkblindxferjune12_2008.txt
( 3) bt-onetouch08052008.txt
( 4) debug-20080821.txt
( 5) park_dyn_feature-20080827.txt
( 6) parking.patch
Description:Using Asterisk 1.4.18, when I try to park a call, I immediatly got a core dump just after playback the parking lot.

CentOS 4.6, i386, kernel 2.6.9-67.0.1 (CentOS).




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

-------------------
bt
-------------------
#0  0x0045cab1 in do_parking_thread (ignore=0x0) at res_features.c:1733
#1  0x08101a1b in dummy_start ()
#2  0x008233cc in start_thread () from /lib/tls/libpthread.so.0
#3  0x0073c1ae in clone () from /lib/tls/libc.so.6


-------------------
bt full
-------------------
#0  0x0045cab1 in do_parking_thread (ignore=0x0) at res_features.c:1733
       __result = 1 '\001'
       f = (struct ast_frame *) 0x84e39bc
       chan = (struct ast_channel *) 0x84e09f0
       tms = 2286
       x = 0
       con = (struct ast_context *) 0x0
       pl = (struct parkeduser *) 0x0
       pt = (struct parkeduser *) 0x0
       ms = -1
       nrfds = {fds_bits = {0 <repeats 32 times>}}
       pu = (struct parkeduser *) 0x84f68c8
       max = -1
       nefds = {fds_bits = {0 <repeats 32 times>}}
       rfds = {fds_bits = {67108864, 0 <repeats 31 times>}}
       efds = {fds_bits = {0 <repeats 32 times>}}
       __PRETTY_FUNCTION__ = "do_parking_thread"
#1  0x08101a1b in dummy_start ()
No symbol table info available.
#2  0x008233cc in start_thread () from /lib/tls/libpthread.so.0
No symbol table info available.
#3  0x0073c1ae in clone () from /lib/tls/libc.so.6
No symbol table info available.
Comments:By: Joel Vandal (jvandal) 2008-02-12 13:38:18.000-0600

After some search (thanks aragon), we found that backtrace from ticket 7090 (http://bugs.digium.com/view.php?id=7090) look pretty similar but 7090 is an issue on Asterisk 1.2.x
By: David Brillert (aragon) 2008-02-13 12:40:34.000-0600

CentOS 4.6, i386, kernel 2.6.9-67.0.1 (CentOS)

Using Asterisk 1.4.18rc3 and I do not get the reported crashes.

I'll upgrade to 1.4.18 official ASAP and see if I can also reproduce on 1.4.18 official.
By: Joel Vandal (jvandal) 2008-02-13 14:00:20.000-0600

When we transfer the call to the Park() application using *1 (BLINDXFER), asterisk crash at each attempts.

If we do a SIP transfer or *2 (ATXFER), all work as expected and no crash.

sip transfer = ok
blindxfer *1 = crash
attended transfer *2 = ok


By: David Brillert (aragon) 2008-02-13 14:12:56.000-0600

I upgraded to 1.4.18 official release.
And ran similar tests
*1 blindxfer to park extension crashes asterisk
*2 atxfer to park extension works
SIP transfer to park extension works
By: Joel Vandal (jvandal) 2008-02-13 14:31:30.000-0600

If I look ticket ASTERISK-8601, this is same problem, asterisk crash once playback the parking lot, but only on blindxfer.


By: David Brillert (aragon) 2008-02-13 16:03:14.000-0600

I ran identical tests on a server with Asterisk 1.4.13 installed
I saw 3 segfaults with 10 test calls blindxfer to park ext

I ran identical tests on same server upgraded to Asterisk 1.4.17
I saw 1 segfault with many calls to blindxfer park ext
This message appeared in logs
[root@productionfw ~]# *** glibc detected *** double free or corruption (!prev): 0x00468aa8 ***

I ran identical tests on same server upgraded to Asterisk 1.4.18
Segfault each time during blindxfer to park ext

Asterisk version 1.4.18
sip transfer = ok
blindxfer *1 = crash
attended transfer *2 = ok
Also same error message as 1.4.17
[root@productionfw /]# *** glibc detected *** double free or corruption (out): 0x097fa6b0 ***
By: Joel Vandal (jvandal) 2008-02-14 10:12:08.000-0600

I have found a way to avoid coredump on Asterisk when doing a blindxfer to Park.

On /etc/asterisk/features.conf, I have change

parkext=700 to parkext=disabled

and on extensions.conf, I have add:

exten => 700,1,Park()

Now call parking work using Blind transfer (*1) and Asterisk doesn't crash !!

Has only 2 issues now with Blindxfer :

- Parking lot announcement is played the parked extensions
- On Call/Ringback, it dial back the parked extensions (look).

But I will probably use ${BLINDTRANSFER} variable to fix this problem and use ParkAndAnnounce only on Blind transfer.



What is the use of parkext, if we can replace this by dialplan ?
By: David Woolley (davidw) 2008-03-12 13:10:43

parkext is implemented by internally adding an entry to the dial plan, so there should be no difference between using parkext and using your explicit entry, except to the extent that uninitialised data is involved, there may be differences in the exact contents of memory.

WHOOPS.  It appears that parkext is magic when accessed via a SIP transfer; the park is done within the SIP channel processing (although it invokes the features module).


By: Clod Patry (junky) 2008-03-13 22:59:18

I will take a look at this during week-end with latest 1.4 and 1.6.0.
By: Joshua C. Colp (jcolp) 2008-05-28 12:08:59

Since Junky hasn't looked at this I'll take a gander but I would like a new complete backtrace as an attachment and exact callflow to reproduce this.
By: David Brillert (aragon) 2008-05-29 13:34:13

file this looks to be related to http://bugs.digium.com/view.php?id=12590
Looks like the reporter attached a backtrace to that ticket

Probably a relation should be made to that ticket or vice versa
By: Jeff Peeler (jpeeler) 2008-06-10 14:24:14

Still at least need the exact method of producing this crash.
By: David Brillert (aragon) 2008-06-10 14:53:55

I thought it was pretty clear

When we transfer the call to the Park() application using *1 (BLINDXFER), asterisk crash at each attempts.

If we do a SIP transfer or *2 (ATXFER), all work as expected and no crash.

sip transfer = ok
blindxfer *1 = crash
attended transfer *2 = ok

Generates segfault

-------------------
bt
-------------------
0 0x0045cab1 in do_parking_thread (ignore=0x0) at res_features.c:1733
1 0x08101a1b in dummy_start ()
2 0x008233cc in start_thread () from /lib/tls/libpthread.so.0
3 0x0073c1ae in clone () from /lib/tls/libc.so.6


-------------------
bt full
-------------------
0 0x0045cab1 in do_parking_thread (ignore=0x0) at res_features.c:1733
       __result = 1 '\001'
       f = (struct ast_frame *) 0x84e39bc
       chan = (struct ast_channel *) 0x84e09f0
       tms = 2286
       x = 0
       con = (struct ast_context *) 0x0
       pl = (struct parkeduser *) 0x0
       pt = (struct parkeduser *) 0x0
       ms = -1
       nrfds = {fds_bits = {0 <repeats 32 times>}}
       pu = (struct parkeduser *) 0x84f68c8
       max = -1
       nefds = {fds_bits = {0 <repeats 32 times>}}
       rfds = {fds_bits = {67108864, 0 <repeats 31 times>}}
       efds = {fds_bits = {0 <repeats 32 times>}}
       __PRETTY_FUNCTION__ = "do_parking_thread"
1 0x08101a1b in dummy_start ()
No symbol table info available.
2 0x008233cc in start_thread () from /lib/tls/libpthread.so.0
No symbol table info available.
3 0x0073c1ae in clone () from /lib/tls/libc.so.6
No symbol table info available.

jvandal changes dialplan (workaround) so there is no segfault

On /etc/asterisk/features.conf, I have change

parkext=700 to parkext=disabled

and on extensions.conf, I have add:

exten => 700,1,Park()
By: Jeff Peeler (jpeeler) 2008-06-10 18:32:35

I can't reproduce the crash using either SIP or ZAP. Please attach a full backtrace as an attachment next time please.
By: Clod Patry (junky) 2008-06-10 23:59:56

aragon: could you attach your features.conf and part of your dialplan that you are using to simplify tests, since neither me or jpeele has been able to reproduce your crash.

Also, you just re-copy your bt full which seems to be with your version of 1.4.18, is that still an issue with 1.4.21-rc2?
By: David Brillert (aragon) 2008-06-11 14:33:53

I will try to revert jvandal's changes on my system and re-test with 1.4.21rc2
I am curious to see if this is fixed in 1.4.21rc2
By: David Brillert (aragon) 2008-06-12 10:33:06

hi junky

Still segfaults with following method
6002 calls 6010
6010 dials *1<parkext=7000>#

Segfault
BT attached
btfull11979parkblindxferjune12_2008.txt

features.conf looks like

[general]
parkext         => 7000
parkpos         => 7001-7010
parkingtime     => 45
context         => parkedcalls
transferdigittimeout => 3
pickupexten     =  *71
featuredigittimeout =  500


[featuremap]
blindxfer       => *1
atxfer          => *2
automon         => *999
disconnect      => *0
parkcall        => ASTERISK-68


By: Jeff Peeler (jpeeler) 2008-06-13 16:00:08

ASTERISK-1  0x0018918d in do_parking_thread (ignore=0x0) at res_features.c:1785
       f = (struct ast_frame *) 0x0
       chan = (struct ast_channel *) 0x979bab8
       tms = 3114
       x = 6
       con = (struct ast_context *) 0x9621928
       pl = (struct parkeduser *) 0x0
       pt = (struct parkeduser *) 0x0
       ms = -1
       nrfds = {fds_bits = {0 <repeats 32 times>}}
       pu = (struct parkeduser *) 0x979aca0
       max = -1
       nefds = {fds_bits = {0 <repeats 32 times>}}
       rfds = {fds_bits = {0 <repeats 32 times>}}
       efds = {fds_bits = {0, 0, 0, 0, 16, 0 <repeats 27 times>}}
---->   parkingslot = "×i\023\bz"
       __PRETTY_FUNCTION__ = "do_parking_thread"

Where did that come from? Can you show me your "core show version" output?


By: David Brillert (aragon) 2008-06-18 11:14:07

jpeeler

I'll continue to use jvandal's workaround
Asterisk isn't crashing using these changes

Anyway my version has changed since and I have yet to test/reproduce on 1.4.21
By: Jeff Peeler (jpeeler) 2008-06-19 09:58:35

Aragon, not sure what you mean by changed. Do you mean modified or upgraded? I still would have liked to see your version output.

Jvandal, still a problem?
By: Joel Vandal (jvandal) 2008-06-19 10:04:55

As specified on previous posted note, here the change we have made :

On /etc/asterisk/features.conf, I have change parkext=700 to parkext=disabled so 'internal' parking will never be executed when someone dial 700

and on extensions.conf, I have define a new extension that execute the Park() application:

exten => 700,1,Park()

If we revert changes (i.e. set parkext=700 and remove the exten => 700), then we have crash issues as described by aragon.
By: Michiel van Baak (mvanbaak) 2008-07-15 13:02:49

Can we get a confirmation that this is still an issue with the latest 1.4 ?
By: mdu113 (mdu113) 2008-07-17 17:54:01

yes, it crashes for me. branch 1.4. revision 131790
here's my backtrace:

(gdb) bt full
#0  0xb7dc0847 in raise () from /lib/tls/libc.so.6
No symbol table info available.
#1  0xb7dc20d9 in abort () from /lib/tls/libc.so.6
No symbol table info available.
#2  0xb7df4616 in __libc_message () from /lib/tls/libc.so.6
No symbol table info available.
#3  0xb7dfad4f in _int_free () from /lib/tls/libc.so.6
No symbol table info available.
#4  0xb7dfb0ea in free () from /lib/tls/libc.so.6
No symbol table info available.
ASTERISK-1  0x08079a7b in ast_cdr_free (cdr=0xb7ec4840) at cdr.c:443
       next = (struct ast_cdr *) 0x8217438
       __PRETTY_FUNCTION__ = "ast_cdr_free"
ASTERISK-2  0x08086b87 in ast_hangup (chan=0x8217040) at channel.c:1516
       res = 0
       __PRETTY_FUNCTION__ = "ast_hangup"
ASTERISK-3  0xb7ab3307 in do_parking_thread (ignore=0x0) at res_features.c:1797
       f = (struct ast_frame *) 0x0
       pl = (struct parkeduser *) 0x0
       pt = (struct parkeduser *) 0x0
       ms = -1
       nrfds = {fds_bits = {0 <repeats 32 times>}}
       pu = (struct parkeduser *) 0x821acf0
       max = -1
       nefds = {fds_bits = {0 <repeats 32 times>}}
       rfds = {fds_bits = {1073741824, 0 <repeats 31 times>}}
       efds = {fds_bits = {0 <repeats 32 times>}}
       __PRETTY_FUNCTION__ = "do_parking_thread"
ASTERISK-4  0x081003f5 in dummy_start (data=0x6) at utils.c:912
       _buffer = {__routine = 0x8068750 <ast_unregister_thread>, __arg = 0xb7aaabb0, __canceltype = 0, __prev = 0x0}
       ret = (void *) 0x8186ba0
       a = {start_routine = 0xb7ab2530 <do_parking_thread>, data = 0x0,
 name = 0x8186ba0 "do_parking_thread    started at [ 2501] res_features.c load_module()"}
ASTERISK-5  0xb7f0720e in start_thread () from /lib/tls/libpthread.so.0
No symbol table info available.
ASTERISK-6 0xb7e610de in clone () from /lib/tls/libc.so.6
No symbol table info available.
By: Giorgio Incantalupo (gincantalupo) 2008-07-22 09:01:15

I'm using Asterisk 1.4.17 on a Debian Etch.
Asterisk always crashes when BLIND-transferring a call to a parking extension ONLY via AGI script. Got no problems if AGI is not used. Tried the jvandal workaround but not enough for a complete substitution of the 'internal' parking.


By: Jeff Peeler (jpeeler) 2008-08-02 22:07:26

mdu113: Does it always crash for you? Tell me what type of devices you are using and which direction the blind transfer is being made. I have yet been able to reproduce the problem.
By: mdu113 (mdu113) 2008-08-05 11:59:26

Since my last report the machine I tested it on has died, so it's probably possible that dying hardware caused some problems. Sorry for the confusion.
Anyway I reinstalled fresh asterisk from svn branch 1.4, r134595 on another test machine which is a little faster (2xP3-800) and here's what I get.
I'm using 2 hardware phones - cisco 7960 and polycom 501. I'm testing parking using attended and blind transfer of these hardware phones plus one-touch parking.
Previously I was getting crashes 100% of the times on any of the 3 scenarios. Sure it could have been due to the machine hardware problems, so I retested everything.
The results:
- parking using both attended and blind transfers on hardware phones seems to work reliable. I cannot reproduce any problems
- one-touch parking seems to work reliable only if the caller initiated the parking (A calls B, B answers, A dials feature code to park B)
- one-touch parking causes crashes if parking is initiated by callee (A calls B, B answers and dials feature code to park A). This happens almost all the time. I did about 20 times and I had 2 or 3 occurences when it didn't crash though, but the parking didn't work also. It just dropped both calls after playing parking announcement.
I've collected several backtraces. They are in file bt-onetouch08052008.txt.
Please let me know if you need any more info.
Thanks
By: Jeff Peeler (jpeeler) 2008-08-18 12:48:02

The only way I have been able to reproduce a crash is for one touch parking to be set to a subset of an usable dynamic feature. If you're using a dynamic feature, please try the attached patch and report back. Just to avoid confusion it might be best to "core set debug 5 res_features.c" and paste the Feature interpret debug lines.
By: mdu113 (mdu113) 2008-08-21 13:01:36

You're right, the one-touch parking is configured with *30, while there's dynamic feature with code *33. It didn't appear to me that it might be related, sorry.
Anyway I've updated asterisk code to the one listed in your patch (r138626) and applied the patch.
When I did the test asterisk still crashed when parking was attempted by callee (actually I see no changes). Then I disabled the dynamic features for the purpose of experiment and tried again. Same result.
So the problem is still there. debug-20080821.txt - is asterisk debug collected as  you suggested and bt-20080821.txt is new backtrace.
Also there's an FastAGI involved (don't know if it matters). Asterisk using FastAGI application for call control.
By: Jeff Peeler (jpeeler) 2008-08-22 15:09:50

The new patch should solve the problem when doing a park on an extension dialed by AGI.

jvandal or aragon, can either of you attach your dialplan?


By: mdu113 (mdu113) 2008-08-26 16:51:12

Yeap! Works for me. Can't reproduce any crash now. Thanks a lot
By: mdu113 (mdu113) 2008-08-27 17:38:41

There's actually one more case when I can get asterisk crashed.
It happens when I execute Park app from agi script that is run by dynamic feature. This only happens if dynamic feature is configured to run on peer.
Here's the setup:
- features.conf:
[applicationmap]
park_caller => *33,peer/callee,AGI,park.agi|park_caller
park_callee => *33,peer/caller,AGI,park.agi|park_callee

- script park.agi:

#!/usr/bin/perl -w

<STDIN>;
print "exec park\n";
<STDIN>;

Attached file - park_dyn_feature-20080827.txt is asterisk log and backtrace.
FYI: if dynamic feature is configured to run the script on "self" channel (self/callee,self/caller) then everything works fine.
I understand that this setup is quite exotic, but it indicates that some problems still exist in the parking code.
By: Jeff Peeler (jpeeler) 2008-09-02 12:57:50

New patch added
By: mdu113 (mdu113) 2008-09-04 10:28:23

Seems to work well now. No crashes so far. Thanks for you work.
By: Jeff Peeler (jpeeler) 2008-09-04 11:50:48

I think all the issues reported here have been solved, so I'm closing this issue. Reopen if further problems persist.
By: Digium Subversion (svnbot) 2008-09-04 11:51:14

Repository: asterisk
Revision: 141028

U   branches/1.4/res/res_agi.c
U   branches/1.4/res/res_features.c

------------------------------------------------------------------------
r141028 | jpeeler | 2008-09-04 11:51:13 -0500 (Thu, 04 Sep 2008) | 7 lines

(closes issue ASTERISK-11424)
Fixes multiple parking problems:
Crash when executing a park on an extension dialed by AGI due to not returning the proper return code.
Crash when using a builtin feature that was a subset of a enabled dynamic feature.
Crash due to always hanging up the peer despite the fact that the peer was supposed to be parked.


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=141028