This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: An increment to Jon Turney's stackdump2backtrace script
- From: Jon Turney <jon dot turney at dronecode dot org dot uk>
- To: The Cygwin Mailing List <cygwin at cygwin dot com>
- Date: Wed, 3 Oct 2018 18:08:17 +0100
- Subject: Re: An increment to Jon Turney's stackdump2backtrace script
- References: <af84c3ce-364e-e058-ac39-ef2713e06cda@maxrnd.com>
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