Summary:	ASTERISK-10790: On certain deadlocks, running core show locks segfaults asterisk and yields no lock info
Reporter:	xmarksthespot (xmarksthespot)	Labels:
Date Opened:	2007-11-16 15:23:58.000-0600	Date Closed:	2007-12-04 18:47:33.000-0600
Priority:	Critical	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) gdb2538cslsegfault.txt ( 1) gdb2538cslsegfaultcorydon.txt ( 2) issue_11275.patch.txt
Description:	My machine occasionally deadlocks. Upon deadlocks I usually run "core show locks" to be able to report bugs with the adequate info concerning deadlocks. However, upon this particular deadlock, the cause of which I have no idea, running "core show locks" at the CLI will segfault asterisk. As it segfaults, the output form core show locks is also incomplete, preventing the possibility of finding out info about the deadlock. This deadlock I am after happens quite often, and running core show locks when asterisk is deadlocked ALWAYS results in a segfault. However, when I was stuck with other deadlocks, core show locks worked perfectly. Since this recent new deadlock appeared, the core show locks function systematically segfaults asterisk. ****** STEPS TO REPRODUCE ****** 1. Manage to get a deadlock 2. Run core show locks 3. Be lucky Like I mentioned, it only happens on this deadlock I am seeing on my machine, and to me it's 100% reproducibility. ****** ADDITIONAL INFORMATION ****** I cannot detail what the deadlock is about, as core show locks won't allow me! I have absolutely no info on the deadlock itself, but I am submitting the bt, bt full, thread apply all bt and thread apply all bt full for this particular crash. As usual, thanks for helping out.
Comments:	By: xmarksthespot (xmarksthespot) 2007-11-16 15:26:11.000-0600 All the gdb info is in the gdb2538cslsegfault.txt file, in that order: bt bt full thread apply all bt thread apply all bt full By: Tilghman Lesher (tilghman) 2007-11-16 15:49:53.000-0600 I need the following output, please: (gdb) frame 3 (gdb) p *buf By: Tilghman Lesher (tilghman) 2007-11-16 15:57:31.000-0600 The other thing you may want to do is update to the latest SVN 1.4.  We've fixed several memory corruption errors, one of which may have caused this issue. By: xmarksthespot (xmarksthespot) 2007-11-23 10:42:24.000-0600 Hi Corydon, I added the output from the gdb commands as you requested, they are in the file gdb2538cslsegfaultcorydon.txt I just uploaded. Only the last line in the file belongs to the second command. I will update to latest SVN as soon as possible. Sorry for the long delay, I only come here 1 day a week, I saw your message earlier but I had network problems that prevented me from doing it before. By: Russell Bryant (russell) 2007-11-23 11:49:17.000-0600 Here, give this patch a try to see if it makes "core show locks" not blow up on you.  It just removes the code that puts the output in an intermediary buffer.  It was the most recent change made to that code. By: xmarksthespot (xmarksthespot) 2007-11-23 12:45:39.000-0600 Will do, however you realize I will have to wait for that particular deadlock to happen again... it's most likely the deadlock linked to issue 10953. Hopefully I can speed up the process by lowering checkmwi to 1 second to force that particular deadlock. By: xmarksthespot (xmarksthespot) 2007-11-28 15:51:39.000-0600 Applying the patch, I noticed one thing: It doesn't compile at first. No big deal, at line 716 you seem to have forgotten a reference to str, I commented it out and it built perfectly. I tried core show locks, and it doesn't segfault right away. Now I have to wait for the crash to occur, and run core show locks. In the meantime I also updated to SVN rev 89999. By: Russell Bryant (russell) 2007-12-04 18:47:32.000-0600 I'm fairly certain I just fixed what caused this in 1.4 revision 91074.