Summary:	ASTERISK-12537: crash if hangup during wait to read
Reporter:	Travis Hein (travishein)	Labels:
Date Opened:	2008-08-07 21:11:42	Date Closed:	2009-03-13 10:28:46
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) bt.txt
Description:	t is as though the read generator feature was not initialized in the channel when this was called.
Comments:	By: Leif Madsen (lmadsen) 2008-08-11 14:23:31 Like the other bug you filed, I think the output of the console and the sip history would be useful in determining what is happening here. Could you provide that? Thanks! By: Travis Hein (travishein) 2008-08-16 00:30:25 Unfortunately, we did not get to capture the console from this one :( By: Mark Michelson (mmichelson) 2008-08-20 10:43:00 If you still have the core dump handy, I'd be interested in knowing the value of chan->generator in frame 0 of the backtrace. You can print this value in gdb using "p chan->generator" By: callguy (callguy) 2008-08-20 10:56:06 putnopvut: unfortunately asterisk was recompiled on here a few days ago, so the backtrace isn't all that useful. i'll see if we still have the old binary archived to run against. By: Eric Futch (efutch) 2008-09-11 14:34:03 Our production PBX just crashed (segmentation fault) in the same spot a little while ago.  We're on version 1.4.21.2.  Asterisk is messing with a NULL pointer. The code in channel.c line 1910 is as follows: if (chan->generator->generate) { Here's relevant parts of what I found in GDB: (gdb) bt 1 #0  ast_read_generator_actions (chan=0xb7b59690, f=0xa241cac) at channel.c:1910 (gdb) print chan.generator $9 = (struct ast_generator *) 0x0 All of this is still fresh on my PBX if you need any more information from me, let me know.  This does explain the crash though. By: Vadim Berezniker (kryptolus) 2008-10-17 09:57:56 I got the same backtrace. 1.4.21.2 Console output before crash is [Oct 17 09:54:55] VERBOSE[28039] logger.c:     -- Stopped music on hold on SIP/XXXXXXXX [Oct 17 09:54:55] DEBUG[28039] chan_sip.c: SIP transfer: Succeeded to masquerade channels. Call came into a queue, answered, put on hold, followed by a transfer attempt By: Leif Madsen (lmadsen) 2008-10-21 14:24:18 Thanks for following up guys. Hopefully this will allow putnopvut the ability to move this issue forward when he has the time. By: Mark Michelson (mmichelson) 2008-10-21 17:54:20 Just updating the issue to say I'm working on it. Things are pretty hectic for me right now, so I'll update further as I have more to say. By: Mark Michelson (mmichelson) 2008-12-11 15:58:13.000-0600 I've probably come back to this issue 15 times since it was assigned to me and I still cannot see a reasonable explanation for why a channel's generatordata would be non-NULL but the channel's generator would be NULL. If this issue is still happening with the latest subversion checkout of 1.4, it would be helpful to see a debug trace of this problem since I'm having a lot of difficulty figuring out how this can be happening. Thanks. By: Vadim Berezniker (kryptolus) 2009-01-27 09:14:46.000-0600 any way it can be related to bug 14086? just a thought. By: Russell Bryant (russell) 2009-02-23 16:07:51.000-0600 I've looked around and haven't found a case that would explain this crash.  I'm marking it as unassigned so others can take a look. If anyone is seeing this crash with the latest version of Asterisk, it would be very useful to know and to see updated debug information. By: Tilghman Lesher (tilghman) 2009-02-26 14:20:02.000-0600 Given the difficulty of figuring this out, it's probably highly advisable to run this under valgrind.  Please see doc/valgrind.txt. By: Russell Bryant (russell) 2009-03-13 10:28:45 A number of developers have taken a look at this and we haven't been able to find anything that could lead to this situation.  We also have not been able to reproduce it. So, given that this was reported a good while ago now, I'm just going to close it out, since it is possible that it has since been resolved. If anyone sees this crash again on a newer version, please let us know! Thanks.