[Bug threads/21117] Occasional wrong thread numbering when following an exec

simon.marchi at ericsson dot com sourceware-bugzilla@sourceware.org
Thu Feb 9 15:26:00 GMT 2017


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

--- Comment #4 from Simon Marchi <simon.marchi at ericsson dot com> ---
(In reply to Pedro Alves from comment #1)
> From the kernel's perspective, it should be the leader lwp that hits the
> breakpoint too, so either a kernel bug, or a gdb bug.  From your logs, looks
> like the latter.
> 
> From the logs, we can tell that the leader/process pid is "19676":
> 
> > process 19676 is executing new program: /home/simark/build/binutils-
> >         ^^^^^
> 
> I think that there's a good hint here, just before the first time we see a
> thread != 1:
> 
> > [New Thread 0x7ffff751a700 (LWP 19697)]
> > [Thread 0x7ffff7f8b700 (LWP 19676) exited] <<<< LEADER DETECTED AS EXITED
> > [New LWP 19676]                            <<<< LEADER RE-ADDED
> > process 19676 is executing new program:    <<<< STILL SAME PID
> > 
> > Thread 10 "mi-nsthrexec" hit Breakpoint 1, main (argc=1, argv=0x7fffffffda98)
> 
> So we detected the leader as exited, deleted it (most probably in
> linux-nat.c:check_zombie_leaders), and then when we get
> the exec event out of the kernel, we re-add the leader thread.
> This will give it a new gdb thread number.
> 
> A "set debug lin-lwp 1" log probably makes that clearer.

That's exactly what I observed.  I put a conditional breakpoint on
delete_thread_1:

  (gdb) b delete_thread_1 if ptid.lwp == ptid.pid

the breakpoint triggers when the bug manifests itself.  We can see that
delete_thread got called from check_zombie_leaders.

That's exactly what

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


More information about the Gdb-prs mailing list