* An increment to Jon Turney's stackdump2backtrace script
@ 2018-10-01 9:21 Mark Geisert
2018-10-03 17:08 ` Jon Turney
0 siblings, 1 reply; 3+ messages in thread
From: Mark Geisert @ 2018-10-01 9:21 UTC (permalink / raw)
To: cygwin
[-- Attachment #1: Type: text/plain, Size: 177 bytes --]
For those Cygwin developers who tend to attract stackdump files...
..mark (who defines an alias 'bt' to launch the script because he can't get gdb
out of his head)
h/t to JT
[-- Attachment #2: stackdump2backtrace --]
[-- Type: text/plain, Size: 2638 bytes --]
#!/bin/bash
#
# stackdump2backtrace (incremented)
# Munges a Cygwin stackdump file into a real backtrace
#
# Based on nifty stackdump2backtrace script by Jon Turney, as
# posted in https://sourceware.org/ml/cygwin/2015-08/msg00311.html
#
# 2018/10/01 increment by Mark A. Geisert
# The user provides the name of the stackdump file
STACKDUMP=$1
if [ -z "$STACKDUMP" ]; then
echo Usage: $0 name-of-stackdump-file
exit 1
fi
if [ ! -e "$STACKDUMP" ]; then
echo cannot find stackdump file $STACKDUMP
exit 1
fi
# Look for executable's best available stashed debug info
IMG1=/usr/lib/debug/usr/bin/${STACKDUMP%.stackdump}.dbg
# If no stashed debug info available for executable, read from EXE
if [ ! -e "$IMG1" ]; then
IMG1=${STACKDUMP%.stackdump}
# If we can't find the EXE, try to locate it with 'which'
if [ ! -e "$IMG1" ]; then
IMG1=`basename $IMG1`
IMG1=`which $IMG1`
fi
fi
# If no luck locating executable image file, bail
if [ ! -e "$IMG1" ]; then
echo cannot find executable file $IMG1
exit 1
fi
# Look for Cygwin DLL's best available stashed debug info
IMG2=/usr/lib/debug/usr/bin/cygwin1.dbg
if [ ! -e "$IMG2" ]; then
IMG2="" # not found; just use what ldd locates later on
fi
# Construct list of image files to resolve addresses against
# Sorting into reverse order seems to improve address lookup performance
OTHERS=`ldd $IMG1 | awk '{print $3}' | sort -r | tr '\\n' ' '`
IMAGES="$IMG1 $IMG2 $OTHERS"
display() {
declare -g IMAGES
# look up address $1 in each known image; break on first success
for img in $IMAGES
do
line=`addr2line -asfiC -e $img $1`
echo $line | fgrep -q "??:0"
if [ $? -ne 0 ]; then
break
fi
done
# state machine for prettier display of addr2line output
addr=""
temp=""
for word in $line
do
case $word in
0x*)
addr=$word
temp=""
;;
\?\?:0 | *.*:*)
echo "$addr | $word | $temp"
addr=" or maybe "
temp=""
;;
*)
temp+="$word "
;;
esac
done
}
# Read and process each stack frame line of the stackdump file
grep "^Exception:" $STACKDUMP
awk '/^[0-9A-F][0-9A-F]/ {print $2}' $STACKDUMP | while read ADDR
do
display $ADDR
done | column -o' ' -t -s'|'
# Deal with register-dump form of stackdump file. No frames here.
COUNT=`grep -c "^[0-9A-F][0-9A-F]" $STACKDUMP`
if [ X"$COUNT" = X0 ]; then
ADDR=`grep "^Exception:" $STACKDUMP | awk '{print $4}' | sed 's/rip=/0x/'`
if [ X"$ADDR" != X ]; then
display $ADDR | column -o' ' -t -s'|'
fi
echo no stack frames present
fi
# And that's all the misinfotainment we have time for
exit 0
[-- Attachment #3: Type: text/plain, Size: 219 bytes --]
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: An increment to Jon Turney's stackdump2backtrace script
2018-10-01 9:21 An increment to Jon Turney's stackdump2backtrace script Mark Geisert
@ 2018-10-03 17:08 ` Jon Turney
2018-10-04 9:18 ` Mark Geisert
0 siblings, 1 reply; 3+ messages in thread
From: Jon Turney @ 2018-10-03 17:08 UTC (permalink / raw)
To: The Cygwin Mailing List
On 01/10/2018 10:20, Mark Geisert wrote:
> For those Cygwin developers who tend to attract stackdump files...
>
> ..mark (who defines an alias 'bt' to launch the script because he can't
> get gdb out of his head)
Nice. Thanks.
> OTHERS=`ldd $IMG1 | awk '{print $3}' | sort -r | tr '\\n' ' '`
One thing you should be aware of here is that you are assuming that the
other DLLs (i) have the same base address locally and on the system
where the stackdump was generated [an assumption which rebase will tend
to invalidate], and (ii) don't get relocated.
(The executable and cygwin1.dll don't suffer from this problem, as they
have fixed addresses in the process memory layout used by cygwin)
For this reason, stackdumps are a weak tool for debugging crashes in
other DLLs. There were some patches posted to add DLL load addresses to
the stackdump, not sure what happened to them...
It would perhaps be better to write a minidump, which captures that
information (and more...)
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: An increment to Jon Turney's stackdump2backtrace script
2018-10-03 17:08 ` Jon Turney
@ 2018-10-04 9:18 ` Mark Geisert
0 siblings, 0 replies; 3+ messages in thread
From: Mark Geisert @ 2018-10-04 9:18 UTC (permalink / raw)
To: cygwin
Jon Turney wrote:
> On 01/10/2018 10:20, Mark Geisert wrote:
>> For those Cygwin developers who tend to attract stackdump files...
>>
>> ..mark (who defines an alias 'bt' to launch the script because he can't get
>> gdb out of his head)
>
> Nice. Thanks.
>
>> OTHERS=`ldd $IMG1 | awk '{print $3}' | sort -r | tr '\\n' ' '`
>
> One thing you should be aware of here is that you are assuming that the other
> DLLs (i) have the same base address locally and on the system where the
> stackdump was generated [an assumption which rebase will tend to invalidate],
> and (ii) don't get relocated.
True. It's geared toward my workflow which only deals with stuff I've built on
my own machine and debugging/fixing pretty soon after causing the stackdump.
Any update to any of the files involved risks invalidating the stackdump.
> (The executable and cygwin1.dll don't suffer from this problem, as they have
> fixed addresses in the process memory layout used by cygwin)
>
> For this reason, stackdumps are a weak tool for debugging crashes in other
> DLLs. There were some patches posted to add DLL load addresses to the
> stackdump, not sure what happened to them...
Huh. I'll see if I can find them in the cygwin-patches archive.
> It would perhaps be better to write a minidump, which captures that information
> (and more...)
Are you alluding specifically to Windows minidump or just generally a small
information dump?
On a related topic, I noticed dumper.exe in winsup/utils and played around with
it. I'm unsure if it captures everything one would want in a corefile. I'm
also unsure if there could even be a PE/COFF corefile and what it would contain.
Cheers,
..mark
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2018-10-04 9:18 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-10-01 9:21 An increment to Jon Turney's stackdump2backtrace script Mark Geisert
2018-10-03 17:08 ` Jon Turney
2018-10-04 9:18 ` Mark Geisert
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).