[Bug threads/28271] New: Crash in GDB-10.2 in thread::detach

[Bug threads/28271] New: Crash in GDB-10.2 in thread::detach

[florin.iucha at amd dot com]

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

            Bug ID: 28271
           Summary: Crash in GDB-10.2 in thread::detach
           Product: gdb
           Version: 10.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: threads
          Assignee: unassigned at sourceware dot org
          Reporter: florin.iucha at amd dot com
  Target Milestone: ---

Building static GDB using crosstool-ng
(https://github.com/cpackham/crosstool-ng/tree/glibc-2.34) using: glibc 2.34,
binutils 2.37, GCC from 11 branch (2e90914b79dd1c591c8a4d663ae2319fbb15df2c),
gdb 10.2 (statically linked) I get crash on startup:


fldiag114 ~/x-tools/x86_64-tng-linux-gnu$ gdb
./x86_64-tng-linux-gnu/debug-root/usr/bin/gdb
GNU gdb (Ubuntu 10.2-0ubuntu1~18.04~2) 10.2
Copyright (C) 2021 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-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://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"...
Traceback (most recent call last):
  File "<string>", line 3, in <module>
ModuleNotFoundError: No module named 'libstdcxx'
/home/fiucha/.gdbinit:7: Error in sourced command file:
Error while executing Python code.
Reading symbols from ./x86_64-tng-linux-gnu/debug-root/usr/bin/gdb...
(gdb) run
Starting program:
/home/fiucha/x-tools/x86_64-tng-linux-gnu/x86_64-tng-linux-gnu/debug-root/usr/bin/gdb
[Detaching after vfork from child process 35124]
[New LWP 35125]

Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x0000000000ac96c9 in std::thread::detach() ()
#2  0x0000000000a4424b in gdb::thread_pool::set_thread_count(unsigned long) ()
#3  0x000000000070be47 in update_thread_pool_size() ()
#4  0x000000000070cb5e in _initialize_maint_cmds() ()
#5  0x00000000008fad52 in initialize_all_files() ()
#6  0x0000000000899f0b in gdb_init(char*) ()
#7  0x0000000000703cb4 in captured_main_1(captured_main_args*) ()
#8  0x0000000000704913 in captured_main(void*) ()
#9  0x000000000070497e in gdb_main(captured_main_args*) ()
#10 0x00000000004022de in main ()
(gdb)

This is running on x86-64, built for x86-64. Os is Ubuntu 18.04 .

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

[Bug threads/28271] Crash in GDB-10.2 in thread::detach

[florin.iucha at amd dot com]

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

--- Comment #1 from Florin Iucha <florin.iucha at amd dot com> ---
It seems this is not dependent on glibc; I have built the same toolchain with
uClibc 1.0.38 and it crashes still:

[Detaching after vfork from child process 67101]
[New LWP 67102]

Thread 1 "x86_64-tng-linu" received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00000000008d2db1 in ?? ()
#2  0x0000000000817cc7 in ?? ()
#3  0x000000000072d07f in ?? ()
#4  0x00000000006dc0ad in ?? ()
#5  0x00000000005e0a18 in ?? ()
#6  0x00000000005e18bb in ?? ()
#7  0x00000000004048bb in ?? ()
#8  0x0000000000905f59 in ?? ()
#9  0x000000000041583a in ?? ()
(gdb) q

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

[Bug threads/28271] Crash in GDB-10.2 in thread::detach

[simark at simark dot ca]

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

Simon Marchi <simark at simark dot ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simark at simark dot ca

--- Comment #2 from Simon Marchi <simark at simark dot ca> ---
Ok, it took me a moment that this had no link with GDB's detach command :).

It's hard to tell what's happening here, as the segault happens in libstdc++ or
equivalent.  Is there a way to build everything (GDB, the C and C++ standard
libraries) with debug info, so we can know where the crash happened?

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

[Bug threads/28271] Crash in GDB-10.2 in thread::detach

[florin.iucha at amd dot com]

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

--- Comment #3 from Florin Iucha <florin.iucha at amd dot com> ---
Alexey reproduced this on a stock build, just by building GDB-10.2 statically:

https://github.com/crosstool-ng/crosstool-ng/pull/1573#issuecomment-906432634

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

[Bug threads/28271] Crash in GDB-10.2 in thread::detach

[alexey.brodkin at gmail dot com]

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

Alexey Brodkin <alexey.brodkin at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alexey.brodkin at gmail dot com

--- Comment #4 from Alexey Brodkin <alexey.brodkin at gmail dot com> ---
With GDB re-built with "-g" in CFLAGS that's what IO see:
------------------------>8--------------------
Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(top-gdb) bt
During symbol reading: incomplete CFI data; unspecified registers (e.g., rax)
at 0xbe1e31
#0  0x0000000000000000 in ?? ()
#1  0x0000000000be1e25 in std::thread::detach() ()
During symbol reading: unsupported tag: 'DW_TAG_unspecified_type'
During symbol reading: Member function "~_Sp_counted_base" (offset 0x3555260)
is virtual but the vtable offset is not specified
During symbol reading: cannot get low and high bounds for subprogram DIE at
0x3560933
During symbol reading: Multiple children of DIE 0x35666d7 refer to DIE
0x356668b as their abstract origin
During symbol reading: Child DIE 0x35701ea and its abstract origin 0x356db92
have different parents
#2  0x0000000000b24c02 in gdb::thread_pool::set_thread_count (this=0x1136930,
num_threads=32) at ../../gdbsupport/thread-pool.cc:106
#3  0x00000000007886e7 in update_thread_pool_size () at ../../gdb/maint.c:775
#4  0x0000000000789637 in _initialize_maint_cmds () at ../../gdb/maint.c:1265
#5  0x00000000009c33c6 in initialize_all_files () at init.c:262
#6  0x0000000000952d58 in gdb_init (argv0=0x1148940 "/host/build/gdb/gdb") at
../../gdb/top.c:2344
#7  0x000000000077f4f5 in captured_main_1 (context=0x7fffffffe5c0) at
../../gdb/main.c:934
#8  0x00000000007802fd in captured_main (data=0x7fffffffe5c0) at
../../gdb/main.c:1243
#9  0x0000000000780374 in gdb_main (args=0x7fffffffe5c0) at
../../gdb/main.c:1268
#10 0x000000000040f3d2 in main (argc=1, argv=0x7fffffffe718) at
../../gdb/gdb.c:32
------------------------>8--------------------

So it looks like a memory/stack corruption which happens in GDB itself.

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

[Bug threads/28271] Crash in GDB-10.2 in thread::detach

[simark at simark dot ca]

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

--- Comment #5 from Simon Marchi <simark at simark dot ca> ---
Perhaps building gdb with address sanitizer will give you an easy answer?

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

[Bug threads/28271] Crash in GDB-10.2 in thread::detach

[alexey.brodkin at gmail dot com]

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

--- Comment #6 from Alexey Brodkin <alexey.brodkin at gmail dot com> ---
Hm, could you please provide some hints on how to enable address sanitizer
while building a static binary?

GCC seems to not like -static & -fsanitize=address used together:
-------------------->8-------------------
cannot specify -static with -fsanitize=address
-------------------->8-------------------

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

[Bug threads/28271] Crash in GDB-10.2 in thread::detach

[simark at simark dot ca]

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

--- Comment #7 from Simon Marchi <simark at simark dot ca> ---
Oh(In reply to Alexey Brodkin from comment #6)
> Hm, could you please provide some hints on how to enable address sanitizer
> while building a static binary?
> 
> GCC seems to not like -static & -fsanitize=address used together:
> -------------------->8-------------------
> cannot specify -static with -fsanitize=address
> -------------------->8-------------------

Oh, I don't know.  I build GDB as a non-static executable, so
-fsanitize=address works here.  Sorry.

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

[Bug threads/28271] Crash in GDB-10.2 in thread::detach

[cbiesinger at google dot com]

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

Christian Biesinger <cbiesinger at google dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cbiesinger at google dot com

--- Comment #8 from Christian Biesinger <cbiesinger at google dot com> ---
May be worth trying valgrind if asan doesn't work?

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

[Bug threads/28271] Crash in GDB-10.2 in thread::detach

[alexey.brodkin at gmail dot com]

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

--- Comment #9 from Alexey Brodkin <alexey.brodkin at gmail dot com> ---
Created attachment 13629
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13629&action=edit
Valgrind log

If of any interest Valgrind log is attached

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

[Bug threads/28271] Crash in GDB-10.2 in thread::detach

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #10 from Tom Tromey <tromey at sourceware dot org> ---
The valgrind trace doesn't seem very useful.
A lot of the complaints in there don't seem like gdb problems though.

(In reply to Alexey Brodkin from comment #4)

> (top-gdb) bt
> During symbol reading: incomplete CFI data; unspecified registers (e.g.,
> rax) at 0xbe1e31
> #0  0x0000000000000000 in ?? ()
> #1  0x0000000000be1e25 in std::thread::detach() ()
...
> So it looks like a memory/stack corruption which happens in GDB itself.

To me it seems the opposite, more like a system and/or libstdc++ thing.
That code in gdb is just:

              std::thread thread (&thread_pool::thread_function, this);
              thread.detach ();

If creating the thread fails, it should throw an exception.
If thread.detach() crashes... it's hard to see the gdb bug here.

You could perhaps try writing a simple std::thread test and seeing 
if that works standalone.  Maybe that would help track it down a little.

Or, when debugging gdb, you could go 'up' to that frame and poke around.

valgrind did report:

==7500== Jump to the invalid address stated on the next line
==7500==    at 0x0: ???
==7500==    by 0x7886E6: update_thread_pool_size() (maint.c:775)
==7500==    by 0x789636: _initialize_maint_cmds() (maint.c:1265)

What's up with that 0x0?  That seems strange.

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