sysmocom
/
asterisk
11
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

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.
........

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@77847 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit is contained in:
Steve Murphy 2007-07-31 21:33:37 +00:00
parent 3257acb922
commit 134d16b3d3
1 changed files with 17 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
contrib/scripts/ast_grab_core
View File

@ -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@localhost"
@ -27,20 +38,16 @@ echo \*\*\* WARNING \*\*\* If the system is not already locked this will cause
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 Done trying for a bt.
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