[Home]

Summary:ASTERISK-14784: Crash during attended transfer occurs
Reporter:Bereterbide Marcelo (marhbere)Labels:
Date Opened:2009-09-07 15:11:32Date Closed:2009-10-08 15:03:54
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Resources/res_musiconhold
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) GDB_bt_full_07092009.TXT
Description:related view.php?id=15460" title="Asterisk Crashed When made a attended Transfer we haven´t any change after the patched.

Now run Asterisk SVN-branch-1.6.0-r215420M
and Asteris-Addons 1.6.0 r1024

Remembering: We are using queue's with SIP static and dynamic members; mho based in File from mp3.
I will attach new GDB, pls tell me if you need something more.



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

Also you see related with that I posted and attached:

https://issues.asterisk.org/view.php?id=15109#109733
https://issues.asterisk.org/file_download.php?file_id=23644&type=bug

https://issues.asterisk.org/view.php?id=15109#109858
https://issues.asterisk.org/file_download.php?file_id=23662&type=bug
Comments:By: Leif Madsen (lmadsen) 2009-09-08 13:32:38

Russell mentioned today to try the patch in issue ASTERISK-14129. There should be a debugging patch there that may help to track down the issue. Thanks!
By: Bereterbide Marcelo (marhbere) 2009-09-08 14:12:22

Ok thank, I´ll wait that the patch be post.

I guess also is related with https://issues.asterisk.org/view.php?id=15841 . regards!
By: Leif Madsen (lmadsen) 2009-09-08 14:42:17

I was under the impression the patch already existed in 15109. If it doesn't, then I'll have to defer to Russell to comment on which patch he was referring to in our meeting this morning.
By: David Brillert (aragon) 2009-09-08 14:56:52

I think you might be referring to the patch in issue ASTERISK-14188
https://issues.asterisk.org/file_download.php?file_id=23674&type=bug

I tested this patch on my open issue ASTERISK-14558 and I still have multiple crashes.  My gdb traces are uploaded to 15609
Here is the link to my gdb dump https://issues.asterisk.org/file_download.php?file_id=23724&type=bug
By: Bereterbide Marcelo (marhbere) 2009-09-10 12:08:33

Aragon, should you wanted refer to 15719.
I can see this patch isn't solving.(
I wonder if the pach in 15109 solved to you some crash, becouse to our always seem still the same issue. In your lab are you made several transfers?
By: David Brillert (aragon) 2009-09-10 12:15:22

I make lots of native attended transfers in tests and none through SIP UA.
Patch in 15109 solved problems while testing under Asterisk 1.4.24 but lots of crashes in SVN 217156 release.  My notes and backtraces are logged in bug ASTERISK-14558 which has been open for some time but severity is open as minor :(

I prefer to work on this issue in my open bug report ASTERISK-14558 rather than constantly referring to my notes in other open tickets...

(0110478)
aragon (reporter)
2009-09-10 09:28
*Another core dump (averaging one per day) running SVN r217156 including patch issue_15179.debug1.diff.txt with patched Asterisk-addons revision 1027
New backtrace core.5134.txt uploaded*
By: Russell Bryant (russell) 2009-09-17 21:59:48

I have posted a new patch to ASTERISK-14558.  Give it a try and let me know if it helps.
By: Bereterbide Marcelo (marhbere) 2009-09-28 16:02:15

At the moment I can´t to apply the patch for tested it becouse we have not a lab scenario and I not sure that it run with lower danger of crashes.

Aragon, I´ll want understand if the last notes in 0015609 are about the description in note "(0110968) russell (administrator) 2009-09-18 09:08" related to point 2?
becouse there are others issues related into the same trunk. and many members have only related with 2, or may I think that this is happening. Then I´m a little confuse. Tks!
By: David Brillert (aragon) 2009-09-28 16:09:17

My last notes are related to bug that was just closed out.
This would be related to the crash itself and not the warnings.
That bug reporter claimed ability to reproduce crash at will.
You can check his notes on ASTERISK-14886
I cannot confirm this since I am running tests currently under Valgrind and that would influence my test results.
By: getmo1 (testing20091001) 2009-10-07 22:57:31

I marked out following code in features.c and it looks fixed my issue 0015962. my one cent.


//      if (res < 0) {
//              finishup(transferee);
//              return -1; /* error ? */
//      }

//      if (res > 0)    /* If they've typed a digit already, handle it */
//              xferto[0] = (char) res;
       ast_stopstream(transferer);
//      res = ast_app_dtget(transferer, transferer_real_context, xferto, sizeof(xferto), 100, transferdigittimeout);
//      if (res < 0) {  /* hangup, would be 0 for invalid and 1 for valid */
//              finishup(transferee);
//              return res;
//      }
//      if (!strcmp(xferto, ast_parking_ext())) {
//              res = finishup(transferee);
//              if (res)
//                      res = -1;
//              else if (!(parkstatus = masq_park_call_announce(transferee, transferer, 0, NULL))) {    /* success */
//                      /* We return non-zero, but tell the PBX not to hang the channel when
//                         the thread dies -- We have to be careful now though.  We are responsible for
//                         hanging up the channel, else it will never be hung up! */
//
//                      return 0;
//              } else {
//                      ast_log(LOG_WARNING, "Unable to park call %s, parkstatus = %d\n", transferee->name, parkstatus);
//              }
//              /*! \todo XXX Maybe we should have another message here instead of invalid extension XXX */
//      } else
By: Digium Subversion (svnbot) 2009-10-08 14:49:22

Repository: asterisk
Revision: 222878

U   branches/1.4/include/asterisk/file.h
U   branches/1.4/include/asterisk/frame.h
U   branches/1.4/main/file.c
U   branches/1.4/main/frame.c

------------------------------------------------------------------------
r222878 | russell | 2009-10-08 14:49:10 -0500 (Thu, 08 Oct 2009) | 44 lines

Make filestream frame handling safer by isolating frames before returning them.

This patch is related to a number of issues on the bug tracker that show
crashes related to freeing frames that came from a filestream.  A number of
fixes have been made over time while trying to figure out these problems, but
there re still people seeing the crash.  (Note that some of these bug reports
include information about other problems.  I am specifically addressing
the filestream frame crash here.)

I'm still not clear on what the exact problem is.  However, what is _very_
clear is that we have seen quite a few problems over time related to unexpected
behavior when we try to use embedded frames as an optimization.  In some cases,
this optimization doesn't really provide much due to improvements made in other
areas.

In this case, the patch modifies filestream handling such that the embedded frame
will not be returned.  ast_frisolate() is used to ensure that we end up with a
completely mallocd frame.  In reality, though, we will not actually have to malloc
every time.  For filestreams, the frame will almost always be allocated and freed
in the same thread.  That means that the thread local frame cache will be used.
So, going this route doesn't hurt.

With this patch in place, some people have reported success in not seeing the
crash anymore.

(SWP-150)
(AST-208)
(ABE-1834)

(issue ASTERISK-14558)
Reported by: aragon
Patches:
     filestream_frisolate-1.4.diff2.txt uploaded by russell (license 2)
Tested by: aragon, russell

(closes issue ASTERISK-14756)
Reported by: zerohalo
Tested by: zerohalo

(closes issue ASTERISK-14784)
Reported by: marhbere

Review: https://reviewboard.asterisk.org/r/386/

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

http://svn.digium.com/view/asterisk?view=rev&revision=222878
By: Digium Subversion (svnbot) 2009-10-08 14:55:35

Repository: asterisk
Revision: 222880

_U  trunk/
U   trunk/include/asterisk/file.h
U   trunk/include/asterisk/frame.h
U   trunk/main/file.c
U   trunk/main/frame.c

------------------------------------------------------------------------
r222880 | russell | 2009-10-08 14:55:26 -0500 (Thu, 08 Oct 2009) | 51 lines

Merged revisions 222878 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
 r222878 | russell | 2009-10-08 14:45:47 -0500 (Thu, 08 Oct 2009) | 44 lines
 
 Make filestream frame handling safer by isolating frames before returning them.
 
 This patch is related to a number of issues on the bug tracker that show
 crashes related to freeing frames that came from a filestream.  A number of
 fixes have been made over time while trying to figure out these problems, but
 there re still people seeing the crash.  (Note that some of these bug reports
 include information about other problems.  I am specifically addressing
 the filestream frame crash here.)
 
 I'm still not clear on what the exact problem is.  However, what is _very_
 clear is that we have seen quite a few problems over time related to unexpected
 behavior when we try to use embedded frames as an optimization.  In some cases,
 this optimization doesn't really provide much due to improvements made in other
 areas.
 
 In this case, the patch modifies filestream handling such that the embedded frame
 will not be returned.  ast_frisolate() is used to ensure that we end up with a
 completely mallocd frame.  In reality, though, we will not actually have to malloc
 every time.  For filestreams, the frame will almost always be allocated and freed
 in the same thread.  That means that the thread local frame cache will be used.
 So, going this route doesn't hurt.
 
 With this patch in place, some people have reported success in not seeing the
 crash anymore.
 
 (SWP-150)
 (AST-208)
 (ABE-1834)
 
 (issue ASTERISK-14558)
 Reported by: aragon
 Patches:
       filestream_frisolate-1.4.diff2.txt uploaded by russell (license 2)
 Tested by: aragon, russell
 
 (closes issue ASTERISK-14756)
 Reported by: zerohalo
 Tested by: zerohalo
 
 (closes issue ASTERISK-14784)
 Reported by: marhbere
 
 Review: https://reviewboard.asterisk.org/r/386/
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=222880
By: Digium Subversion (svnbot) 2009-10-08 14:57:53

Repository: asterisk
Revision: 222881

_U  branches/1.6.0/
U   branches/1.6.0/include/asterisk/file.h
U   branches/1.6.0/include/asterisk/frame.h
U   branches/1.6.0/main/file.c
U   branches/1.6.0/main/frame.c

------------------------------------------------------------------------
r222881 | russell | 2009-10-08 14:57:44 -0500 (Thu, 08 Oct 2009) | 58 lines

Merged revisions 222880 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r222880 | russell | 2009-10-08 14:52:03 -0500 (Thu, 08 Oct 2009) | 51 lines
 
 Merged revisions 222878 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r222878 | russell | 2009-10-08 14:45:47 -0500 (Thu, 08 Oct 2009) | 44 lines
   
   Make filestream frame handling safer by isolating frames before returning them.
   
   This patch is related to a number of issues on the bug tracker that show
   crashes related to freeing frames that came from a filestream.  A number of
   fixes have been made over time while trying to figure out these problems, but
   there re still people seeing the crash.  (Note that some of these bug reports
   include information about other problems.  I am specifically addressing
   the filestream frame crash here.)
   
   I'm still not clear on what the exact problem is.  However, what is _very_
   clear is that we have seen quite a few problems over time related to unexpected
   behavior when we try to use embedded frames as an optimization.  In some cases,
   this optimization doesn't really provide much due to improvements made in other
   areas.
   
   In this case, the patch modifies filestream handling such that the embedded frame
   will not be returned.  ast_frisolate() is used to ensure that we end up with a
   completely mallocd frame.  In reality, though, we will not actually have to malloc
   every time.  For filestreams, the frame will almost always be allocated and freed
   in the same thread.  That means that the thread local frame cache will be used.
   So, going this route doesn't hurt.
   
   With this patch in place, some people have reported success in not seeing the
   crash anymore.
   
   (SWP-150)
   (AST-208)
   (ABE-1834)
   
   (issue ASTERISK-14558)
   Reported by: aragon
   Patches:
         filestream_frisolate-1.4.diff2.txt uploaded by russell (license 2)
   Tested by: aragon, russell
   
   (closes issue ASTERISK-14756)
   Reported by: zerohalo
   Tested by: zerohalo
   
   (closes issue ASTERISK-14784)
   Reported by: marhbere
   
   Review: https://reviewboard.asterisk.org/r/386/
 ........
................

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

http://svn.digium.com/view/asterisk?view=rev&revision=222881
By: Digium Subversion (svnbot) 2009-10-08 15:01:00

Repository: asterisk
Revision: 222882

_U  branches/1.6.1/
U   branches/1.6.1/include/asterisk/file.h
U   branches/1.6.1/include/asterisk/frame.h
U   branches/1.6.1/main/file.c
U   branches/1.6.1/main/frame.c

------------------------------------------------------------------------
r222882 | russell | 2009-10-08 15:00:51 -0500 (Thu, 08 Oct 2009) | 58 lines

Merged revisions 222880 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r222880 | russell | 2009-10-08 14:52:03 -0500 (Thu, 08 Oct 2009) | 51 lines
 
 Merged revisions 222878 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r222878 | russell | 2009-10-08 14:45:47 -0500 (Thu, 08 Oct 2009) | 44 lines
   
   Make filestream frame handling safer by isolating frames before returning them.
   
   This patch is related to a number of issues on the bug tracker that show
   crashes related to freeing frames that came from a filestream.  A number of
   fixes have been made over time while trying to figure out these problems, but
   there re still people seeing the crash.  (Note that some of these bug reports
   include information about other problems.  I am specifically addressing
   the filestream frame crash here.)
   
   I'm still not clear on what the exact problem is.  However, what is _very_
   clear is that we have seen quite a few problems over time related to unexpected
   behavior when we try to use embedded frames as an optimization.  In some cases,
   this optimization doesn't really provide much due to improvements made in other
   areas.
   
   In this case, the patch modifies filestream handling such that the embedded frame
   will not be returned.  ast_frisolate() is used to ensure that we end up with a
   completely mallocd frame.  In reality, though, we will not actually have to malloc
   every time.  For filestreams, the frame will almost always be allocated and freed
   in the same thread.  That means that the thread local frame cache will be used.
   So, going this route doesn't hurt.
   
   With this patch in place, some people have reported success in not seeing the
   crash anymore.
   
   (SWP-150)
   (AST-208)
   (ABE-1834)
   
   (issue ASTERISK-14558)
   Reported by: aragon
   Patches:
         filestream_frisolate-1.4.diff2.txt uploaded by russell (license 2)
   Tested by: aragon, russell
   
   (closes issue ASTERISK-14756)
   Reported by: zerohalo
   Tested by: zerohalo
   
   (closes issue ASTERISK-14784)
   Reported by: marhbere
   
   Review: https://reviewboard.asterisk.org/r/386/
 ........
................

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

http://svn.digium.com/view/asterisk?view=rev&revision=222882
By: Digium Subversion (svnbot) 2009-10-08 15:03:51

Repository: asterisk
Revision: 222883

_U  branches/1.6.2/
U   branches/1.6.2/include/asterisk/file.h
U   branches/1.6.2/include/asterisk/frame.h
U   branches/1.6.2/main/file.c
U   branches/1.6.2/main/frame.c

------------------------------------------------------------------------
r222883 | russell | 2009-10-08 15:03:42 -0500 (Thu, 08 Oct 2009) | 58 lines

Merged revisions 222880 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r222880 | russell | 2009-10-08 14:52:03 -0500 (Thu, 08 Oct 2009) | 51 lines
 
 Merged revisions 222878 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r222878 | russell | 2009-10-08 14:45:47 -0500 (Thu, 08 Oct 2009) | 44 lines
   
   Make filestream frame handling safer by isolating frames before returning them.
   
   This patch is related to a number of issues on the bug tracker that show
   crashes related to freeing frames that came from a filestream.  A number of
   fixes have been made over time while trying to figure out these problems, but
   there re still people seeing the crash.  (Note that some of these bug reports
   include information about other problems.  I am specifically addressing
   the filestream frame crash here.)
   
   I'm still not clear on what the exact problem is.  However, what is _very_
   clear is that we have seen quite a few problems over time related to unexpected
   behavior when we try to use embedded frames as an optimization.  In some cases,
   this optimization doesn't really provide much due to improvements made in other
   areas.
   
   In this case, the patch modifies filestream handling such that the embedded frame
   will not be returned.  ast_frisolate() is used to ensure that we end up with a
   completely mallocd frame.  In reality, though, we will not actually have to malloc
   every time.  For filestreams, the frame will almost always be allocated and freed
   in the same thread.  That means that the thread local frame cache will be used.
   So, going this route doesn't hurt.
   
   With this patch in place, some people have reported success in not seeing the
   crash anymore.
   
   (SWP-150)
   (AST-208)
   (ABE-1834)
   
   (issue ASTERISK-14558)
   Reported by: aragon
   Patches:
         filestream_frisolate-1.4.diff2.txt uploaded by russell (license 2)
   Tested by: aragon, russell
   
   (closes issue ASTERISK-14756)
   Reported by: zerohalo
   Tested by: zerohalo
   
   (closes issue ASTERISK-14784)
   Reported by: marhbere
   
   Review: https://reviewboard.asterisk.org/r/386/
 ........
................

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

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