public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* 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).