[Bug gdb/31008] New: „Layout” crashes gdb 13.2

[Bug gdb/31008] New: „Layout” crashes gdb 13.2

[zbigniew2011 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31008

            Bug ID: 31008
           Summary: „Layout” crashes gdb 13.2
           Product: gdb
           Version: 13.1
            Status: UNCONFIRMED
          Severity: critical
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: zbigniew2011 at gmail dot com
  Target Milestone: ---

Hello,

I tried to make use out of „layout” command by trying „layout split” and
„layout regs” — in both cases gdb crashes spitting out „memory protection
error” (and „A fatal error internal to GDB has been detected, further debugging
is not possible.  GDB will now terminate.”).

Slackware64 15.0, kernel 6.1.28, gdb 13.2, Intel CPU.

BTW, one question: ARM32 gdb (10.1.90) doesn't recognize „layout” at all. Is it
a bug, or it's supposed to not recognize „layout”?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31008] „Layout” crashes gdb 13.2

[zbigniew2011 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31008

--- Comment #1 from Zbigniew <zbigniew2011 at gmail dot com> ---
Just verified, that when using AArch64 package „gdb 12.1” it seems to accept
„layout” commands with (so far) no problem. Tested on Orange Pi 800, using its
„stock” Linux distro, derived from Ubuntu.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31008] „Layout” crashes gdb 13.2

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31008

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
                 CC|                            |tromey at sourceware dot org
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2023-10-30

--- Comment #2 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to Zbigniew from comment #0)
> Hello,
> 
> I tried to make use out of „layout” command by trying „layout split” and
> „layout regs” — in both cases gdb crashes spitting out „memory protection
> error” (and „A fatal error internal to GDB has been detected, further
> debugging is not possible.  GDB will now terminate.”).

These both work fine for me on Fedora 38.
I tested by running my gdb 13 build on itself, then entering the
commands.  Did you do something different?

Perhaps getting a stack trace from gdb, if that's possible,
would be informative.

> BTW, one question: ARM32 gdb (10.1.90) doesn't recognize „layout” at all. Is
> it a bug, or it's supposed to not recognize „layout”?

This probably means it was built without TUI support.
This can happen if, e.g., you don't have curses installed
when configuring.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31008] „Layout” crashes gdb 13.2

[zbigniew2011 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31008

--- Comment #3 from Zbigniew <zbigniew2011 at gmail dot com> ---
Created attachment 15201
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15201&action=edit
Strace output

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31008] „Layout” crashes gdb 13.2

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31008

--- Comment #4 from Tom Tromey <tromey at sourceware dot org> ---
strace shows a trace of system calls that gdb uses.
Unfortunately this isn't very useful for diagnosing
this particular problem.  What's needed instead is
a stack trace at the point of the crash.  (It isn't
guaranteed this will help but it might.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31008] „Layout” crashes gdb 13.2

[zbigniew2011 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31008

--- Comment #5 from Zbigniew <zbigniew2011 at gmail dot com> ---
Let me know step-by-step, what actually you want me to do.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31008] „Layout” crashes gdb 13.2

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31008

--- Comment #6 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to Zbigniew from comment #5)
> Let me know step-by-step, what actually you want me to do.

I would try 'gdb gdb', then produce the crash and then 'bt'
to get a stack trace.

However, this is only really useful if you have gdb debug info
available.  I don't know how to get that for your distro.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31008] „Layout” crashes gdb 13.2

[zbigniew2011 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31008

--- Comment #7 from Zbigniew <zbigniew2011 at gmail dot com> ---
Do I need to recompile gdb with some particular option? On that little ARM32 I
wouldn't dare — it would take several hours — but my Intel machine isn't that
slow, so I can recompile, if it's of any use.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31008] „Layout” crashes gdb 13.2

[zbigniew2011 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31008

--- Comment #8 from Zbigniew <zbigniew2011 at gmail dot com> ---
OK, so I simply ran gdb, and then — as root — connected to its PID using
another instance. Then I switched logging on.
After I „continue”-d (as root), the „debugee” allowed to enter commands, then I
entered „layout regs”. So it displayed THE EMPTY FRAME in the upper part of
terminal window, and after I „continue”-d again, it crashed. The log contents
is quite short:

---------------- logged output ------------------------
Continuing.

Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
0x00007efe93097318 in delwin () from /lib64/libncursesw.so.6
Continuing.

Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
0x00007efe92eaf258 in raise () from /lib64/libpthread.so.0
Detaching from program: /usr/bin/gdb, process 22745
[Inferior 1 (process 22745) detached]

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31008] „Layout” crashes gdb 13.2

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31008

--- Comment #9 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to Zbigniew from comment #7)
> Do I need to recompile gdb with some particular option? On that little ARM32
> I wouldn't dare — it would take several hours — but my Intel machine isn't
> that slow, so I can recompile, if it's of any use.

If you are building it yourself, do a clean build and add this to
the configure command line:

... configure CXXFLAGS='-g -O0' ...other args...

This should get a better stack trace than the one you got.

I wonder if something is messed up in your curses installation.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31008] „Layout” crashes gdb 13.2

[zbigniew2011 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31008

--- Comment #10 from Zbigniew <zbigniew2011 at gmail dot com> ---
OK, I recompiled and I did everything like before — here's the output:

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/gdb...
(No debugging symbols found in /usr/bin/gdb)
Attaching to program: /usr/bin/gdb, process 23373
[New LWP 23375]
[New LWP 23376]
[New LWP 23377]
[New LWP 23378]
[New LWP 23379]
--Type <RET> for more, q to quit, c to continue without paging--
[New LWP 23380]
[New LWP 23381]
[New LWP 23382]
[New LWP 23383]
[New LWP 23384]
[New LWP 23385]
[New LWP 23386]
[New LWP 23387]
[New LWP 23388]
[New LWP 23389]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
0x00007f81589217cf in poll () from /lib64/libc.so.6
warning: File "/home/zb/.gdbinit" auto-loading has been declined by your
`auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
        add-auto-load-safe-path /home/zb/.gdbinit
line to your configuration file "/root/.config/gdb/gdbinit".
To completely disable this security protection add
        set auto-load safe-path /
line to your configuration file "/root/.config/gdb/gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
        info "(gdb)Auto-loading safe path"
(gdb) cont
Continuing.

Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
0x00007f81596fc318 in delwin () from /lib64/libncursesw.so.6
(gdb) cont
Continuing.

line to your configuration file "/root/.config/gdb/gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
        info "(gdb)Auto-loading safe path"
(gdb) cont
Continuing.

Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
0x00007f81596fc318 in delwin () from /lib64/libncursesw.so.6
(gdb) cont
Continuing.

Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
0x00007f8159516258 in raise () from /lib64/libpthread.so.0
(gdb) cont
Continuing.
Couldn't get registers: Nie ma takiego procesu.
(gdb) [Thread 0x7f8137fff640 (LWP 23389) exited]
[Thread 0x7f814c815640 (LWP 23388) exited]
[Thread 0x7f814d016640 (LWP 23387) exited]
[Thread 0x7f814d817640 (LWP 23386) exited]
[Thread 0x7f814e018640 (LWP 23385) exited]
[Thread 0x7f814e819640 (LWP 23384) exited]
[Thread 0x7f814ffff640 (LWP 23383) exited]
[Thread 0x7f8155016640 (LWP 23382) exited]
[Thread 0x7f8155817640 (LWP 23381) exited]
[Thread 0x7f8156018640 (LWP 23380) exited]
[Thread 0x7f8156819640 (LWP 23379) exited]
[Thread 0x7f815701a640 (LWP 23378) exited]
[Thread 0x7f814f01a640 (LWP 23377) exited]
[Thread 0x7f815781b640 (LWP 23376) exited]
[Thread 0x7f815801c640 (LWP 23375) exited]

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.


Regarding my ncurses installation:

I admit I use patched ncurses — the patch has been provided by Mr. T. Dickey,
ncurses maintainer, after I reported a bug. Here it is:

; ------------ quote -----------------
It's a one-line fix, which can easily be back-ported:

--- ncurses/curses.priv.h       2023/06/03 12:33:07     1.668
+++ ncurses/curses.priv.h       2023/06/06 22:31:04     1.669
@@ -1498,7 +1498,7 @@
 #define isWidecExt(ch) (0)
 #define if_WIDEC(code) /* nothing */

-#define Charable(ch)   ((ch) >= ' ' && (ch) <= '~')
+#define Charable(ch)   (CharOf(ch) >= ' ' && CharOf(ch) <= '~')
 #define L(ch)          ch
 #endif /* } */
; ----------- end of quote -----------

Please, note: of course most probably this patch will be included into next
„official” release of ncurses, therefore gdb should tolerate it — you'll get
many more bug reports otherwise.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31008] „Layout” crashes gdb 13.2

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31008

--- Comment #11 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to Zbigniew from comment #10)
> OK, I recompiled and I did everything like before — here's the output:

> Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
> 0x00007f81596fc318 in delwin () from /lib64/libncursesw.so.6
> (gdb) cont
> Continuing.

Right here you should invoke "bt" (rather than "cont") to get the stack trace.
Posting it here would be good.

This crash occurs in delwin, in libncurses.  This does not necessarily
mean a curses bug.  The next step would be to examine the output of 
"bt" and look for the first frame that is in the gdb sources.
You can go there with "frame 5" (e.g., if it is frame #5), then
you can look at the local variables and whatnot.
Normally in gdb this will be some destructor.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31008] „Layout” crashes gdb 13.2

[zbigniew2011 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31008

--- Comment #12 from Zbigniew <zbigniew2011 at gmail dot com> ---
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/gdb...
(No debugging symbols found in /usr/bin/gdb)
Attaching to program: /usr/bin/gdb, process 3390
[New LWP 3392]
[New LWP 3393]
[New LWP 3394]
[New LWP 3395]
[New LWP 3396]
[New LWP 3397]
[New LWP 3398]
[New LWP 3399]
[New LWP 3400]
[New LWP 3401]
[New LWP 3402]
[New LWP 3403]
[New LWP 3404]
[New LWP 3405]
[New LWP 3406]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
0x00007f7d533217cf in poll () from /lib64/libc.so.6
warning: File "/home/zb/.gdbinit" auto-loading has been declined by your
`auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
        add-auto-load-safe-path /home/zb/.gdbinit
line to your configuration file "/root/.config/gdb/gdbinit".
To completely disable this security protection add
        set auto-load safe-path /
line to your configuration file "/root/.config/gdb/gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
        info "(gdb)Auto-loading safe path"
(gdb)  cont
Continuing.

Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
0x00007f7d540a5318 in delwin () from /lib64/libncursesw.so.6
(gdb) bt
#0  0x00007f7d540a5318 in delwin () from /lib64/libncursesw.so.6
#1  0x00000000008fba3c in ?? ()
#2  0x00000000008fc44e in ?? ()
#3  0x00000000008fc131 in ?? ()
#4  0x0000000000a7debb in ?? ()
#5  0x0000000000a696a0 in ?? ()
#6  0x0000000000a69b44 in ?? ()
#7  0x0000000000a69e89 in ?? ()
#8  0x0000000000a69ea7 in ?? ()
#9  0x0000000000568eee in ?? ()
#10 0x000000000056dc44 in ?? ()
#11 0x0000000000a3beb5 in ?? ()
#12 0x00000000006df846 in ?? ()
#13 0x00000000006dfd16 in ?? ()
#14 0x0000000000a641b4 in ?? ()
#15 0x00000000006df021 in ?? ()
#16 0x00007f7d541def9e in rl_callback_read_char ()
   from /usr/lib64/libreadline.so.8
#17 0x00000000006dee70 in ?? ()
#18 0x00000000006def26 in ?? ()
#19 0x00000000006df679 in ?? ()
#20 0x0000000000bbbe93 in ?? ()
#21 0x0000000000bbc432 in ?? ()
#22 0x0000000000bbb3a5 in ?? ()
#23 0x0000000000815979 in ?? ()
#24 0x0000000000815a9e in ?? ()
#25 0x00000000008172a6 in ?? ()
#26 0x000000000081730c in ?? ()
#27 0x0000000000418a2d in ?? ()
#28 0x00007f7d5324503d in __libc_start_main () from /lib64/libc.so.6
#29 0x000000000041893a in ?? ()
(gdb) cont
Continuing.

Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
0x00007f7d53ebf258 in raise () from /lib64/libpthread.so.0
(gdb) bt
#0  0x00007f7d53ebf258 in raise () from /lib64/libpthread.so.0
#1  0x00000000006e0114 in ?? ()
#2  0x00000000006e019c in ?? ()
#3  <signal handler called>
#4  0x00007f7d540a5318 in delwin () from /lib64/libncursesw.so.6
#5  0x00000000008fba3c in ?? ()
#6  0x00000000008fc44e in ?? ()
#7  0x00000000008fc131 in ?? ()
#8  0x0000000000a7debb in ?? ()
#9  0x0000000000a696a0 in ?? ()
#10 0x0000000000a69b44 in ?? ()
#11 0x0000000000a69e89 in ?? ()
#12 0x0000000000a69ea7 in ?? ()
#13 0x0000000000568eee in ?? ()
#14 0x000000000056dc44 in ?? ()
#15 0x0000000000a3beb5 in ?? ()
#16 0x00000000006df846 in ?? ()
#17 0x00000000006dfd16 in ?? ()
#18 0x0000000000a641b4 in ?? ()
#19 0x00000000006df021 in ?? ()
#20 0x00007f7d541def9e in rl_callback_read_char ()
   from /usr/lib64/libreadline.so.8
#21 0x00000000006dee70 in ?? ()
#22 0x00000000006def26 in ?? ()
#23 0x00000000006df679 in ?? ()
#24 0x0000000000bbbe93 in ?? ()
#25 0x0000000000bbc432 in ?? ()
#26 0x0000000000bbb3a5 in ?? ()
#27 0x0000000000815979 in ?? ()
#28 0x0000000000815a9e in ?? ()
#29 0x00000000008172a6 in ?? ()
#30 0x000000000081730c in ?? ()
#31 0x0000000000418a2d in ?? ()
#32 0x00007f7d5324503d in __libc_start_main () from /lib64/libc.so.6
#33 0x000000000041893a in ?? ()
(gdb) cont
Continuing.
Couldn't get registers: Nie ma takiego procesu.
(gdb) [Thread 0x7f7d36ffd640 (LWP 3406) exited]
[Thread 0x7f7d377fe640 (LWP 3405) exited]
[Thread 0x7f7d37fff640 (LWP 3404) exited]
[Thread 0x7f7d3ccf9640 (LWP 3403) exited]
[Thread 0x7f7d3d4fa640 (LWP 3402) exited]
[Thread 0x7f7d3dcfb640 (LWP 3401) exited]
[Thread 0x7f7d3e4fc640 (LWP 3400) exited]
[Thread 0x7f7d3effd640 (LWP 3399) exited]
[Thread 0x7f7d3f7fe640 (LWP 3398) exited]
[Thread 0x7f7d3ffff640 (LWP 3397) exited]
[Thread 0x7f7d509bb640 (LWP 3396) exited]
[Thread 0x7f7d511bc640 (LWP 3395) exited]
[Thread 0x7f7d519bd640 (LWP 3394) exited]
[Thread 0x7f7d521be640 (LWP 3393) exited]
[Thread 0x7f7d529bf640 (LWP 3392) exited]

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31008] „Layout” crashes gdb 13.2

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31008

--- Comment #13 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to Zbigniew from comment #12)
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from /usr/bin/gdb...
> (No debugging symbols found in /usr/bin/gdb)

I think you still don't have debug symbols...


> (gdb) bt
> #0  0x00007f7d540a5318 in delwin () from /lib64/libncursesw.so.6
> #1  0x00000000008fba3c in ?? ()
> #2  0x00000000008fc44e in ?? ()
> #3  0x00000000008fc131 in ?? ()
> #4  0x0000000000a7debb in ?? ()
> #5  0x0000000000a696a0 in ?? ()

... stack trace makes this clear.

So unfortunately this doesn't really tell us anything.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31008] „Layout” crashes gdb 13.2

[zbigniew2011 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31008

--- Comment #14 from Zbigniew <zbigniew2011 at gmail dot com> ---
But this is what I've got following your description.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31008] „Layout” crashes gdb 13.2

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31008

--- Comment #15 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to Zbigniew from comment #14)
> But this is what I've got following your description.

Did you do a clean rebuild per comment #9?
You can check using "readelf -WS" on the executable
(or the one in the build tree) and looking for the debug
sections.

I tend to suspect this is a problem somewhere on your
system -- either in how you built curses or how you 
built gdb -- because gdb works completely fine on
all other Linux systems.  E.g. I use it there every day.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31008] „Layout” crashes gdb 13.2

[zbigniew2011 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31008

--- Comment #16 from Zbigniew <zbigniew2011 at gmail dot com> ---
readelf -WS /usr/bin/gdb gives the following answer:


There are 31 section headers, starting at offset 0xce7bd0:

Section Headers:
  [Nr] Name              Type            Address          Off    Size   ES Flg
Lk Inf Al
  [ 0]                   NULL            0000000000000000 000000 000000 00     
0   0  0
  [ 1] .interp           PROGBITS        0000000000400350 000350 00001c 00   A 
0   0  1
  [ 2] .note.gnu.property NOTE            0000000000400370 000370 000030 00   A
 0   0  8
  [ 3] .note.ABI-tag     NOTE            00000000004003a0 0003a0 000020 00   A 
0   0  4
  [ 4] .hash             HASH            00000000004003c0 0003c0 00205c 04   A 
6   0  8
  [ 5] .gnu.hash         GNU_HASH        0000000000402420 002420 000528 00   A 
6   0  8
  [ 6] .dynsym           DYNSYM          0000000000402948 002948 006150 18   A 
7   1  8
  [ 7] .dynstr           STRTAB          0000000000408a98 008a98 005285 00   A 
0   0  1
  [ 8] .gnu.version      VERSYM          000000000040dd1e 00dd1e 00081c 02   A 
6   0  2
  [ 9] .gnu.version_r    VERNEED         000000000040e540 00e540 000370 00   A 
7  10  8
  [10] .rela.dyn         RELA            000000000040e8b0 00e8b0 0009d8 18   A 
6   0  8
  [11] .rela.plt         RELA            000000000040f288 00f288 005328 18  AI 
6  26  8
  [12] .init             PROGBITS        0000000000415000 015000 000017 00  AX 
0   0  4
  [13] .plt              PROGBITS        0000000000415020 015020 003780 10  AX 
0   0 16
  [14] .text             PROGBITS        00000000004187a0 0187a0 7d31ce 00  AX 
0   0 16
  [15] .fini             PROGBITS        0000000000beb970 7eb970 000009 00  AX 
0   0  4
  [16] .rodata           PROGBITS        0000000000bec000 7ec000 23e34a 00   A 
0   0 32
  [17] .eh_frame_hdr     PROGBITS        0000000000e2a34c a2a34c 079664 00   A 
0   0  4
  [18] .eh_frame         PROGBITS        0000000000ea39b0 aa39b0 2039e0 00   A 
0   0  8
  [19] .gcc_except_table PROGBITS        00000000010a7390 ca7390 02b410 00   A 
0   0  4
  [20] .tbss             NOBITS          00000000010d4430 cd3430 000410 00 WAT 
0   0  8
  [21] .init_array       INIT_ARRAY      00000000010d4430 cd3430 0004c8 08  WA 
0   0  8
  [22] .fini_array       FINI_ARRAY      00000000010d48f8 cd38f8 000008 08  WA 
0   0  8
  [23] .data.rel.ro      PROGBITS        00000000010d4900 cd3900 000388 00  WA 
0   0 32
  [24] .dynamic          DYNAMIC         00000000010d4c88 cd3c88 000340 10  WA 
7   0  8
  [25] .got              PROGBITS        00000000010d4fc8 cd3fc8 000030 08  WA 
0   0  8
  [26] .got.plt          PROGBITS        00000000010d5000 cd4000 001bd0 08  WA 
0   0  8
  [27] .data             PROGBITS        00000000010d6be0 cd5be0 011ec2 00  WA 
0   0 32
  [28] .bss              NOBITS          00000000010e8ac0 ce7aa2 023e60 00  WA 
0   0 32
  [29] .comment          PROGBITS        0000000000000000 ce7aa2 000012 01  MS 
0   0  1
  [30] .shstrtab         STRTAB          0000000000000000 ce7ab4 000118 00     
0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  R (retain), D (mbind), l (large), p (processor specific)


Is it clean, or „dirty”?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31008] „Layout” crashes gdb 13.2

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31008

--- Comment #17 from Tom Tromey <tromey at sourceware dot org> ---
Debug info will be a section like `.debug_info`.

prentzel. readelf -WS ./gdb/gdb | grep debug
  [31] .debug_aranges    PROGBITS        0000000000000000 1d777f4 02c620 00    
 0   0  1
  [32] .debug_info       PROGBITS        0000000000000000 1da3e14 a7379b5 00   
  0   0  1
  [33] .debug_abbrev     PROGBITS        0000000000000000 c4db7c9 3b9016 00    
 0   0  1
  [34] .debug_line       PROGBITS        0000000000000000 c8947df e87b9c 00    
 0   0  1
  [35] .debug_str        PROGBITS        0000000000000000 d71c37b 1015dc0 01 
MS  0   0  1
  [36] .debug_line_str   PROGBITS        0000000000000000 e73213b 0103d9 01  MS
 0   0  1
  [37] .debug_loclists   PROGBITS        0000000000000000 e742514 193ec4f 00   
  0   0  1
  [38] .debug_rnglists   PROGBITS        0000000000000000 10081163 3a99bd 00   
  0   0  1


So maybe your rebuild didn't go correctly?
I don't know anything about how your distro works,
so I have no idea how you would do this.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31008] „Layout” crashes gdb 13.2

[zbigniew2011 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31008

--- Comment #18 from Zbigniew <zbigniew2011 at gmail dot com> ---
Is it possible that my build doesn't go correctly each time? What — in your
opinion — should I correct/change?
Every other software I compiled for my distro seems to be working just fine.
Why exactly gdb shouldn't?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31008] „Layout” crashes gdb 13.2

[zbigniew2011 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31008

--- Comment #19 from Zbigniew <zbigniew2011 at gmail dot com> ---
Here's the list of „configure” options from „slackbuild” script used to build 
gdb:

../configure CXXFLAGS='-g -O0' \
  --prefix=/usr \
  --libdir=/usr/lib${LIBDIRSUFFIX} \
  --mandir=/usr/man \
  --infodir=/usr/info \
  $GUILE_OPTION \
  --with-python=/usr/bin/python3 \
  --with-system-readline \
  --with-system-zlib \
  --build=$ARCH-slackware-linux || exit 1

Apart of CXXFLAGS added on your request, it's a standard script taken from
Slackware64-current.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31008] „Layout” crashes gdb 13.2

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31008

--- Comment #20 from Tom Tromey <tromey at sourceware dot org> ---
Can you look at your build directory to see if 'gdb/gdb' there has
debug info?  If so you can run that one to get a decent stack trace.

(In reply to Zbigniew from comment #18)
> Is it possible that my build doesn't go correctly each time? What — in your
> opinion — should I correct/change?
> Every other software I compiled for my distro seems to be working just fine.
> Why exactly gdb shouldn't?

I don't know what kind of response you're expecting to this sort of
statement.  We don't know why.  Most programs don't use curses, either.

-- 
You are receiving this mail because:
You are on the CC list for the bug.