Re: An increment to Jon Turney's stackdump2backtrace script

[Mark Geisert <mark@maxrnd.com>]

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