Web lists-archives.com

Re: An increment to Jon Turney's stackdump2backtrace script

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.


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