[asterisk-commits] murf: trunk r77847 - in /trunk: ./ contrib/scripts/ast_grab_core

[SVN commits to the Asterisk project]

Author: murf
Date: Tue Jul 31 16:33:37 2007
New Revision: 77847

URL: http://svn.digium.com/view/asterisk?view=rev&rev=77847
Log:
Merged revisions 77844 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/branches/1.4

................
r77844 | murf | 2007-07-31 14:59:10 -0600 (Tue, 31 Jul 2007) | 9 lines

Merged revisions 77842 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/branches/1.2

........
r77842 | murf | 2007-07-31 13:19:35 -0600 (Tue, 31 Jul 2007) | 1 line

This probably isn't super-general, but it's a first stab at using kill -11 to generate a core file instead of gcore.
........

................

Modified:
    trunk/   (props changed)
    trunk/contrib/scripts/ast_grab_core

Propchange: trunk/
------------------------------------------------------------------------------
Binary property 'branch-1.4-merged' - no diff available.

Modified: trunk/contrib/scripts/ast_grab_core
URL: http://svn.digium.com/view/asterisk/trunk/contrib/scripts/ast_grab_core?view=diff&rev=77847&r1=77846&r2=77847
==============================================================================
--- trunk/contrib/scripts/ast_grab_core (original)
+++ trunk/contrib/scripts/ast_grab_core Tue Jul 31 16:33:37 2007
@@ -3,8 +3,19 @@
 # lame quickie script to snarf a core of a hung asterisk process.
 # bugs to ast_grab_core, blinky-lights.org  (derrick daugherty)
 
+# we have found that gcore doesn't yield as useful a core file
+# as that yielded by a signal-caused core dump. So we are going to change
+# the strategy to sending a SEGV signal to the asterisk process,
+# and have it 'burn to the ground', leaving behind a core file.
+# the main difference is that you cannot control where the
+# core file will end up. We will assume that safe_asterisk was
+# used to start asterisk, and the core file should therefore end
+# up in /tmp (because safe_asterisk cd's there before starting asterisk).
+# if this is not the case, set DUMPDIR to the place where the core
+# file can be found.
+
 DATE=`date +%Y%m%d%H%M`
-DUMPDIR=/var/tmp
+DUMPDIR=/tmp
 HOSTNAME=`hostname`
 ADMINEMAIL="root at localhost"
 
@@ -27,20 +38,16 @@
 echo \*\*\* WARNING \*\*\*  process to STOP while memory is dumped to disk.
 echo
 
-/usr/bin/gdb > /dev/null << EOF
-	attach ${PID}
-	gcore ${DUMPDIR}/asterisk_${DATE}.core.${PID}
-	detach
-	quit
-EOF
+/bin/kill -11 ${PID}
 
-echo Snarfed!  ${DUMPDIR}/asterisk_${DATE}.core.${PID}
+echo Snarfed!  ${DUMPDIR}/core.${PID}
 echo
 
 
 echo Trying for a backtrace of the captured core.
-/usr/bin/gdb /usr/sbin/asterisk ${DUMPDIR}/asterisk_${DATE}.core.${PID} > ${DUMPDIR}/gdb_dump.${PID}.txt 2> /dev/null << EOF
+/usr/bin/gdb /usr/sbin/asterisk ${DUMPDIR}/core.${PID} > ${DUMPDIR}/gdb_dump.${PID}.txt 2> /dev/null << EOF
 set prompt \n
+set print pretty\n
 echo --------------------------------------------------------------------------------\n
 echo INFO THREAD
 info thread
@@ -56,7 +63,7 @@
 
 
 echo Notifying admins of the core.
-/usr/bin/mail -s "${HOSTNAME} core dumped at ${DUMPDIR}/asterisk_${DATE}.core.${PID}" ${ADMINEMAIL} < /tmp/gdb_dump.${PID}
+/usr/bin/mail -s "${HOSTNAME} core dumped at ${DUMPDIR}/core.${PID}" ${ADMINEMAIL} < ${DUMPDIR}/gdb_dump.${PID}.txt
 echo Done.
 echo
 echo Reproducible deadlocks should be posted with a full backtrace and instructions