RE: dumper does not produce core that gdb recognizes?

RE: dumper does not produce core that gdb recognizes?

[Lavrentiev, Anton (NIH/NLM/NCBI) [C]]

> I've learned that once I get a setup that seems to be stable

That's what I thought about my 3.2.0 setup, too, but following your own
conclusions about the rolling release, one can never be sure...

Anyways, maybe it's time for me to upgrade.  I did not because it looked
like 3.3 was coming out with a lot of new issues (as people were reporting),
so I just froze all upgrades.  Looks like 3.3 is now stabilized as 3.4 is
getting ready LOL

> This was fixed in gdb-10.1-1 [1] (upstream in gdb 11) and cygwin 3.1.7.

Well, I've got cygwin 3.2.0 (which supposedly was expected to be "good" already)
yet gdb 9.2 at the same time...  Oh well, that rolling release...

Thanks for all the replies, though, I really appreciate it!

Anton Lavrentiev
Contractor NIH/NLM/NCBI

Re: dumper does not produce core that gdb recognizes?

[Jon Turney]

On 09/07/2022 01:58, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
>> The latest version of gdb that is not a test version is 11.2. But
>> you are using 9.2.
> 
> I am using the older dumper as well, my working cygwin is not cutting edge.
> 
> $ dumper -V
> dumper (cygwin) 3.2.0
> 
> What I am coming at is that if dumper is not consistent with gdb,
> that does not make any sense.  They should always be consistent at
> any given time, so if the packages (dumper's and gdb's) installed together,
> they would be able to cooperate. 

Ideally, that would be the case.

Unfortunately, for a long time, on x86_64, dumper wasn't working 
correctly, and gdb couldn't read those dumps, and nobody cared enough to 
do anything about it.

This was fixed in gdb-10.1-1 [1] (upstream in gdb 11) and cygwin 3.1.7.

If you choose to use earlier versions on x86_64, it's a known defect 
that it won't work.

[1] https://cygwin.com/pipermail/cygwin-announce/2020-October/009752.html

Re: dumper does not produce core that gdb recognizes?

[Brian Inglis]

On 2022-07-08 19:31, Backwoods BC wrote:
> On Fri, Jul 8, 2022 at 5:59 PM Lavrentiev, Anton (NIH/NLM/NCBI) wrote:
>>> The latest version of gdb that is not a test version is 11.2. But
>>> you are using 9.2.

>> I am using the older dumper as well, my working cygwin is not cutting edge.
>> $ dumper -V
>> dumper (cygwin) 3.2.0
>> What I am coming at is that if dumper is not consistent with gdb,
>> that does not make any sense.  They should always be consistent at
>> any given time, so if the packages (dumper's and gdb's) installed together,
>> they would be able to cooperate.

> I've encountered similar issues with other things in Cygwin. The fact
> that it is a rolling release means that there is no such thing as a
> stable release. I've been using Cygwin for at least 20 years and I've
> learned that once I get a setup that seems to be stable, I do not
> upgrade anything unless there is a very pressing reason to do so.

You have a few moving parts in the chain here - binutils, gcc, gdb, 
dumper (cygwin), and Windows, that are all being updated asynchronously, 
and have to use and handle features provided by each other, so parts are 
always out of sync, and need tweaked to keep up.
As this is a volunteer project, toolchain internals are complex and 
takes time to understand, comprehension, knowledge, experience are rare, 
and time is scarce, dumper sometimes lags to the detriment of 
debuggability.

> This is a pain in the butt, but it is what it is. I still find that
> Cygwin is better suited than WSL for my primary needs of writing
> scripts and filters to make my life in Windows easier.

WSL adds its own issues. I found if I want to compare (with) Linux 
distros and behaviours, I need to use VMs.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Re: dumper does not produce core that gdb recognizes?

[Backwoods BC]

On Fri, Jul 8, 2022 at 5:59 PM Lavrentiev, Anton (NIH/NLM/NCBI) [C]
via Cygwin <cygwin@cygwin.com> wrote:
>
> > The latest version of gdb that is not a test version is 11.2. But
> > you are using 9.2.
>
> I am using the older dumper as well, my working cygwin is not cutting edge.
>
> $ dumper -V
> dumper (cygwin) 3.2.0
>
> What I am coming at is that if dumper is not consistent with gdb,
> that does not make any sense.  They should always be consistent at
> any given time, so if the packages (dumper's and gdb's) installed together,
> they would be able to cooperate.
>
> Anton Lavrentiev
> Contractor NIH/NLM/NCBI

I've encountered similar issues with other things in Cygwin. The fact
that it is a rolling release means that there is no such thing as a
stable release. I've been using Cygwin for at least 20 years and I've
learned that once I get a setup that seems to be stable, I do not
upgrade anything unless there is a very pressing reason to do so.

This is a pain in the butt, but it is what it is. I still find that
Cygwin is better suited than WSL for my primary needs of writing
scripts and filters to make my life in Windows easier.

RE: dumper does not produce core that gdb recognizes?

[Lavrentiev, Anton (NIH/NLM/NCBI) [C]]

> The latest version of gdb that is not a test version is 11.2. But
> you are using 9.2.

I am using the older dumper as well, my working cygwin is not cutting edge.

$ dumper -V
dumper (cygwin) 3.2.0

What I am coming at is that if dumper is not consistent with gdb,
that does not make any sense.  They should always be consistent at
any given time, so if the packages (dumper's and gdb's) installed together,
they would be able to cooperate.

Anton Lavrentiev
Contractor NIH/NLM/NCBI

Re: dumper does not produce core that gdb recognizes?

[Ken Brown]

On 7/8/2022 6:06 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
> Hi all,
> 
> I need to do some deep debugging on Cygwin so I need to produce a core...  And it does not work.
> 
> So I reduced the problem to this minimal test case:
> 
> $ cat a.c
> #include <stdlib.h>
> 
> int main()
> {
>      abort();
> }
> 
> $ gcc -Wall -g a.c
> 
> $ echo $CYGWIN
> error_start=c:\cygwin64\bin\dumper.exe
> 
> $ ulimit -a
> core file size          (blocks, -c) unlimited
> data seg size           (kbytes, -d) unlimited
> file size               (blocks, -f) unlimited
> open files                      (-n) 3200
> pipe size            (512 bytes, -p) 8
> stack size              (kbytes, -s) 2036
> cpu time               (seconds, -t) unlimited
> max user processes              (-u) 256
> virtual memory          (kbytes, -v) unlimited
> 
> $ ./a
> *** starting debugger for pid 19934, tid 9332
> 
> $ ls -l a.*
> -rw-r--r-- 1 ANTON None      49 Jul  8 17:40 a.c
> -rwxr-xr-x 1 ANTON None  161487 Jul  8 17:41 a.exe*
> -rw-r--r-- 1 ANTON None 3331640 Jul  8 17:46 a.exe.core
> 
> $ file a.*
> a.c:        C source, ASCII text
> a.exe:      PE32+ executable (console) x86-64, for MS Windows
> a.exe.core: ELF 64-bit LSB core file, x86-64, version 1 (SYSV)
> 
> BUT: gdb does not want this core file:
> 
> $ gdb ./a.exe a.exe.core
> GNU gdb (GDB) (Cygwin 9.2-1) 9.2
> Copyright (C) 2020 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "x86_64-pc-cygwin".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
>      <http://www.gnu.org/software/gdb/documentation/>.
> 
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from ./a.exe...
> "/home/ANTON/a.exe.core": no core file handler recognizes format
> (gdb)
> 
> What I am doing wrong?

Try using a more recent gdb.  I just tried your test case with gdb-12.1-1 
(available as a test release), and it seemed to work.

Ken

dumper does not produce core that gdb recognizes?

[Lavrentiev, Anton (NIH/NLM/NCBI) [C]]

Hi all,

I need to do some deep debugging on Cygwin so I need to produce a core...  And it does not work.

So I reduced the problem to this minimal test case:

$ cat a.c
#include <stdlib.h>

int main()
{
    abort();
}

$ gcc -Wall -g a.c

$ echo $CYGWIN
error_start=c:\cygwin64\bin\dumper.exe

$ ulimit -a
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
file size               (blocks, -f) unlimited
open files                      (-n) 3200
pipe size            (512 bytes, -p) 8
stack size              (kbytes, -s) 2036
cpu time               (seconds, -t) unlimited
max user processes              (-u) 256
virtual memory          (kbytes, -v) unlimited

$ ./a
*** starting debugger for pid 19934, tid 9332

$ ls -l a.*
-rw-r--r-- 1 ANTON None      49 Jul  8 17:40 a.c
-rwxr-xr-x 1 ANTON None  161487 Jul  8 17:41 a.exe*
-rw-r--r-- 1 ANTON None 3331640 Jul  8 17:46 a.exe.core

$ file a.*
a.c:        C source, ASCII text
a.exe:      PE32+ executable (console) x86-64, for MS Windows
a.exe.core: ELF 64-bit LSB core file, x86-64, version 1 (SYSV)

BUT: gdb does not want this core file:

$ gdb ./a.exe a.exe.core
GNU gdb (GDB) (Cygwin 9.2-1) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./a.exe...
"/home/ANTON/a.exe.core": no core file handler recognizes format
(gdb)

What I am doing wrong?

TIA,

Anton Lavrentiev
Contractor NIH/NLM/NCBI