Re: [PATCH 1/4] Add sniffer for Cygwin x86_64 core dumps

[Simon Marchi <simark@simark.ca>]

On 2020-08-22 3:52 p.m., Jon Turney wrote:
> On 22/08/2020 20:41, Simon Marchi wrote:
>> On 2020-08-21 12:28 p.m., Jon Turney wrote:
>>> On 21/08/2020 17:22, Simon Marchi wrote:
>>>> On 2020-08-21 11:25 a.m., Jon Turney wrote:
>>>>> The "dumper" currently shipping in x86_64 Cygwin is utterly broken. (See [1] et seq.).
>>>>>
>>>>> If you use "dumper" from the latest snapshot [2], you may have more success
>>>>>
>>>>> [1] https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=7dd1b08836e8a7bb37d330995096540afce152a0;hp=38f88601469f4a6ab7cf42e1f076775c99eb17f2
>>>>> [2] https://cygwin.com/snapshots/
>>>>
>>>> Ok, thanks for the tip.  I'll give it a try with a snapshot.
>>>>
>>>> Do I just extract cygwin-20200821.tar.xz into my current Cygwin installation to overwrite
>>>> the corresponding files?  If I want to revert to the stable versions, how can I do that?
>>>
>>> You should be able to just extract the dumper.exe from that archive, and
>>> use it.  That's what I would suggest.
>>
>> Hmm, just tried that, now running "dumper" does nothing:
>>
>> Baube@DESKTOP-42816MD ~
>> $ dumper
>>
>> Baube@DESKTOP-42816MD ~
>> $ echo $?
>> 127
> 
> Hmmm.  This often means the executable can't be started due to problems 
> loading DLLs.
> 
> If you want to pursue this further, running under cygwin's strace (e.g. 
> 'strace dumper') might shed more light.

Ahh, I downloaded the x86 version of the snapshot instead of the x86-64!

When using dumper.exe from the x86-64, it works.  I that dumper.exe from the
snapshot also runs much faster than the original dumper.exe, don't know if that's
expected.

I now get this:

$ ./gdb -q --data-directory=data-directory ~/a.exe -ex "core ~/core.core"
Reading symbols from /home/simark/a.exe...
warning: core file may not match specified executable file.
[New process 6408]
[New process 6504]
[New process 904]
[New process 5068]
[New process 4892]
#0  0x00007ff92bba01b4 in ?? ()
[Current thread is 1 (process 6408)]
(gdb) bt
#0  0x00007ff92bba01b4 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Since I just copied my binary and core out of Cygwin, and the program was stopped somewhere
under sleep(), it's perhaps expected that GDB has trouble unwinding from system libraries
it doesn't have access to.

Simon