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

["tromey at sourceware dot org" <sourceware-bugzilla@sourceware.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.