[Home]

Summary:ASTERISK-17058: [patch] Asterisk 1.8.1-rc1 crashes in cdr.c line 1201 after a parked call catched with parkedcall() is hungup
Reporter:Andy Brodmann (macbrody)Labels:
Date Opened:2010-12-03 08:10:57.000-0600Date Closed:2010-12-10 08:30:27.000-0600
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:CDR/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 20101209__issue18415.diff.txt
( 1) backtrace.txt
( 2) backtrace-18415-1.8.0.txt
( 3) backtrace-18415-1.8.1-rc1.txt
( 4) backtrace-18415-1.8.1-rc1-park.txt
( 5) extensions.conf
( 6) patch-18415
Description:The following combination makes asterisk-1.8.1-rc1 crash in cdr.c no matter if
there is any config file for cdr or not:

call gets parked:
exten => _*81ZXX,n,Park(120000,CTX_ParkTimeout,s,1,s)

other person picks up the call:
exten => _*82ZXX,n,Set(CDR(userfield)=${USERFIELD})
exten => _*82ZXX,n,ParkedCall(${EXTEN:3})

either party hangs up:
asterisk crashes creating a core dump.

The output of the core dump in gdb:
>Core was generated by `/opt/asterisk/sbin/asterisk -f -vvvg -c'.
>Program terminated with signal 11, Segmentation fault.
>#0  ast_cdr_specialized_reset (cdr=0x0, _flags=0x0) at cdr.c:1201
>1201            if (ast_test_flag(cdr, AST_CDR_FLAG_POST_DISABLED)) { /* But do NOT lose the NoCDR() setting */


Comments:By: Paul Belanger (pabelanger) 2010-12-04 21:07:38.000-0600

Thank you for your bug report. In order to move your issue forward, we require a backtrace from the core file produced after the crash. Please see the doc/backtrace.txt file in your Asterisk source directory.

Also, be sure you have DONT_OPTIMIZE enabled in menuselect within the Compiler Flags section, then:

make install

after enabling, reproduce the crash, and then execute the instructions in doc/backtrace.txt.

When complete, attach that file to this issue report. Thanks!

By: jsolares (jsolares) 2010-12-05 00:34:05.000-0600

I experienced a similar problem in 1.8.0 whilst doing MusicOnHold(default) on a channel and then using the Bridge app on another call to the first channel, upon either hangup it crashed on the same spot, with cdr also being null, i had to enclose most of ast_cdr_specialized_rest's content with a if ( cdr ) for it to work, i'll see if i can get a backtrace going tomorrow or monday morning.

By: jsolares (jsolares) 2010-12-05 18:09:34.000-0600

added a backtrace from 1.8.0 doing something similar to parking (bridging calls), i believe it's the same issue. take note that i'm crashing at line 1202 because i commented out my "fix" ( if (cdr) enclosing most of that function ), i'm using the MusicOnHold/Bridge apps instead of Park/ParkedCall.

edit 1: added another backtrace now from 1.8.1-rc1, i haven't used park/parkedcall at all to try and duplicate the exact same issue described by the OP, however i still believe they are related.

edit 2:
The problem is that, Set(CDR(userfield)=${USERFIELD}) in conjunction with bridging two incoming channels apparently.

i just took out the CDR(userfield) setting from my own agi and it stopped crashing.

also another thing, i have 8 priorities in my h extension for finalizing the call, after hanging up it gets sent to 10, and then does the auto fallthrough and goes thru the 8 priorities.

   -- Executing [h@inbound:10] NoOp("SIP/jsolares-00000006", "Weird") in new stack
   -- Auto fallthrough, channel 'SIP/jsolares-00000006' status is 'UNKNOWN'
   -- Executing [h@inbound:1] GotoIf("SIP/jsolares-00000006", "0?7:2") in new stack

edit 3: Added the simplest config that i found that fails, a Set(CDR(userfield)=...) on the parked/musiconhold channel will cause asterisk to crash when hang up, whilst having it on the parkedcall/bridge wont, also added backtrace for this extensions.conf

peer_cdr is not null, any reason why it would be different than peer->cdr (and this null) at the end of the bridge?



By: jsolares (jsolares) 2010-12-06 15:18:06.000-0600

found the problem, and why it only crashes when cdr(userfield) is set, line 3163 has a peer->cdr = NULL, and it's only set when copying over the userfield.

/* copy the userfield from the B-leg to A-leg if applicable */
       if (chan->cdr && peer->cdr && !ast_strlen_zero(peer->cdr->userfield)) {
               char tmp[256];
               if (!ast_strlen_zero(chan->cdr->userfield)) {
                       snprintf(tmp, sizeof(tmp), "%s;%s", chan->cdr->userfield, peer->cdr->userfield);
                       ast_cdr_appenduserfield(chan, tmp);
               } else
                       ast_cdr_setuserfield(chan, peer->cdr->userfield);
               /* free the peer's cdr without ast_cdr_free complaining */
               ast_free(peer->cdr);
               peer->cdr = NULL;
       }

so the userfield gets copied over from peer to chan, but then peer->cdr gets freed, i don't know enough of the code to know why we should do it tho.

By: jsolares (jsolares) 2010-12-06 16:03:41.000-0600

added a patch, it solves the problem on my end both for a park/parkedcall bridge and my musiconhold/bridge solution.

By: Andy Brodmann (macbrody) 2010-12-07 01:26:49.000-0600

I just added a backtrace.txt to the original issue.

I can confirm that it only happens when you set the CDR(userfield).

Is this all you need from our side Paul?

By: jsolares (jsolares) 2010-12-07 09:01:13.000-0600

mac, try the patch i attached, it should show up now since yay i'm not a robot so the license is ok now, it's very minor, and it works with 1.8.0, 1.8.1-rc1 and latest svn.

By: Tilghman Lesher (tilghman) 2010-12-09 00:58:26.000-0600

It's probably better if we do effectively the same thing, but without actually deleting the CDR.  In other words, we should probably disable the CDR from posting.

By: jsolares (jsolares) 2010-12-09 08:49:16.000-0600

what actually happens afaict is that a bridge_cdr is created and posted at the end of ast_bridge_call whilst the cdrs for chan and peer get reset (where it was crashing) with ast_cdr_specialized_reset, so it won't post unless you have it configured to post unanswered channels (maybe)

also remember that it was only setting the peer->cdr to null when CDR(userfield) was set on peer.



By: Leif Madsen (lmadsen) 2010-12-09 10:19:58.000-0600

This looks like it will make it into the current sprint, so it should be resolved in 1.8.3-rc1.

By: Digium Subversion (svnbot) 2010-12-09 14:48:45.000-0600

Repository: asterisk
Revision: 297952

U   branches/1.8/main/features.c

------------------------------------------------------------------------
r297952 | twilson | 2010-12-09 14:48:44 -0600 (Thu, 09 Dec 2010) | 10 lines

Don't crash after Set(CDR(userfield)=...) in ast_bridge_call

Instead of setting peer->cdr = NULL, set it to not post.

(closes issue ASTERISK-17058)
Reported by: macbrody
Patches:
     patch-18415 uploaded by jsolares (license 1167)
Tested by: jsolares, twilson

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

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

By: Digium Subversion (svnbot) 2010-12-09 15:26:20.000-0600

Repository: asterisk
Revision: 297956

_U  trunk/
U   trunk/main/features.c

------------------------------------------------------------------------
r297956 | twilson | 2010-12-09 15:26:19 -0600 (Thu, 09 Dec 2010) | 17 lines

Merged revisions 297952 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8

........
 r297952 | twilson | 2010-12-09 14:48:44 -0600 (Thu, 09 Dec 2010) | 10 lines
 
 Don't crash after Set(CDR(userfield)=...) in ast_bridge_call
 
 Instead of setting peer->cdr = NULL, set it to not post.
 
 (closes issue ASTERISK-17058)
 Reported by: macbrody
 Patches:
       patch-18415 uploaded by jsolares (license 1167)
 Tested by: jsolares, twilson
........

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

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

By: Leif Madsen (lmadsen) 2010-12-10 08:30:27.000-0600

Looks like this made it in time, so it will indeed be part of 1.8.2-rc1 (not 1.8.3-rc1 as originally scheduled).