Summary:	ASTERISK-12347: ChanSpy multiple channels attached to one
Reporter:	JonBFS (bfsworks)	Labels:
Date Opened:	2008-07-09 08:38:02	Date Closed:	2008-12-16 10:35:15.000-0600
Priority:	Critical	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_chanspy
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) bt.txt ( 1) bt1.txt ( 2) bt2.txt ( 3) bt-2008-07-09T18:03:52.txt ( 4) bt3.txt ( 5) bt4.txt ( 6) bt5.txt ( 7) bt6.txt ( 8) gdb.txt
Description:	Chanspy seems to be crashing when multiple sip channels are reading from the same channel(s). For example in a call center environment if trainee 1 and trainee 2 dial an extension that runs chanspy and they happen spy on the same sip conversation then a segfault will occur. This is only reproducible if multiple sip reads occur on a channel.
Comments:	By: JonBFS (bfsworks) 2008-07-09 08:43:53 Running on production system so have to schedule a recompile not optimized to get full info. Wanted to post for now in case other reporters have similar issue. By: Mark Michelson (mmichelson) 2008-07-09 09:45:21 I couldn't reproduce this in my sample setup here. Could you provide the sip.conf and indicate which peer was being spied on and which peers were doing the spying? Also, what options are being passed to the Chanspy application? By: JonBFS (bfsworks) 2008-07-09 17:03:45 I will have full recreation details by Monday. Posted new bt which is different but still looks like chanspy. Following is how chanspy is being executed: exten => s,1,Wait(1) exten => s,n,ChanSpy(SIP/${MACRO_EXTEN:5}|g(${ARG1})) exten => s,n,Hangup Using group filtering... By: Mark Michelson (mmichelson) 2008-07-16 14:45:36 I took another crack at this today and still could not manage to get a crash to occur. Perhaps if you can, could you run Asterisk under valgrind? The instructions for doing so are located in doc/valgrind.txt. Thanks. By: JonBFS (bfsworks) 2008-07-22 09:42:01 Still investigating could not reproduce as expected might be related to Bug 0013124 . Although the severity is more then just failing, still causes segfaults. By: Arnd Schmitter (arnd) 2008-07-23 05:23:08 Hi, i've hit the same problem with my asterisk. Currently I'm running 1.4.18.1 on the production system, where the problems occured. I will try to get reproduce the Problem with my development system and try to get a valgrind report. By: JonBFS (bfsworks) 2008-08-01 13:32:16 Updated to include patch submitted to Bug 0013124. This bug must be unrelated because it did not resolve the issue. Have not had time to report further. Mostly occurring when two people are scanning channels and when the same channel is targeted by two chanspy processes a segfault occurs. That is the best I have for now. Hopefully arnd reporter can provide more information sooner. By: Peng Yong (ppyy) 2008-08-03 23:24:40 same problem on Asterisk 1.4.21.2? crash frequently By: cmaj (cmaj) 2008-08-04 09:48:35 I just observed this crash on 1.4.21.1, with ChanSpy(|qg(xx)), identical BT to the first posted on this bug.  All SIP callers and monitors.  It may have been 2 people monitoring at once that caused it. But it's worse than that... I am also getting reports of frequent no audio on the spied upon channels.  And "show channels" sometimes shows several "ChanSpy" instances floating around -- even if the monitor hangs up, I think they linger until the caller hangs up.  Whenever I see more than one or two of these stuck channels, I also notice that my system load spikes really bad, so it starts to sap the entire box. Can anybody point to the last stable version of 1.4 that they used ChanSpy w/SIP heavily on?  I wanted to confirm the bug report and am willing to test on my dev system but I'm stuck right now on production.  Thanks! By: snuffy (snuffy) 2008-09-11 18:10:18 The upcoming 1.4.22 release has some fixes relating to chanspy Please try the RC listed on the asterisk.org main page By: Mark Michelson (mmichelson) 2008-12-10 12:57:21.000-0600 So here's something I'd like to consider on this issue. I've noticed that all the people who have provided a sample dialplan for their crash have been using the 'g' option to ChanSpy. There was an issue which was fixed with regards to this option where a stack overflow would occur eventually due to a busy loop which kept allocating new stack data. This bug fix is present in 1.4.22. I think that it may be that this is the same basic issue which is causing this, but I have no way to be sure of it. The clues that are tipping me off on this are that the crashes don't always appear to be happening in the same place, they do not appear to have anything to do with accessing freed or invalid memory, and they appear to happen in what would otherwise seem to be uncrashable places. The problem with this idea is that I can't really see any reason why having multiple people spying on a single channel would cause the problem. It would be really great if someone running 1.4.22 or one of the 1.4.23 release candidates could determine if this issue still occurs in those versions. By: Wolfgang Pichler (wuwu) 2008-12-11 01:31:27.000-0600 I have had the same problem with 1.4.21.2 - the crash was not reproduceable - but did always happen with chanspy... The upgrade to 1.4.22 did fix it for me. By: Mark Michelson (mmichelson) 2008-12-11 07:06:37.000-0600 That's good news indeed. I'm going to leave this bug open for another day or two in case someone says that the problem does still exist in 1.4.22. Thank you for the feedback. By: Mark Michelson (mmichelson) 2008-12-16 10:35:14.000-0600 Given that I have a confirmation that the bug is fixed and I haven't heard anyone say that it is not fixed, I am going to close this issue. If it turns out that the problem still exists in 1.4.22 and above, then please either re-open this issue or open a new bug report. Thank you.