This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFC: nptl threading patch for linux
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: "J. Johnston" <jjohnstn at redhat dot com>
- Cc: gdb-patches at sources dot redhat dot com, roland at redhat dot com
- Date: Sun, 17 Aug 2003 16:49:27 -0400
- Subject: Re: RFC: nptl threading patch for linux
- References: <3EA84E74.3010101@redhat.com> <20030509220011.GA22383@nevyn.them.org> <20030510211855.GA4312@nevyn.them.org> <20030510215939.GA4907@nevyn.them.org> <3EBFF7C3.2000905@redhat.com>
On Mon, May 12, 2003 at 03:36:35PM -0400, J. Johnston wrote:
> >
> >I could cause segfaults in both the inferior and GDB, and some missed
> >single-steps. I don't know if my kernel patch is at fault or your
> >patch, but I figured I'd write them up anyway for posterity and later
> >review.
> >
> >Start with gdb.threads/print-threads. Put a breakpoint on
> >thread_function and one on the printf ("Done\n") main. Run, disable
> >the first breakpoint when you hit it, and say next. You'll hit the
> >breakpoint in main instead of staying within thread_function.
> >
>
> This does not fail on my test system. I end up on line 42 after the next
> is issued.
Using 2.5.72 on a single-processor machine, which is what I had lying
around today, I could still reproduce it. I don't think it's new;
rather, I think it's annoying.
We single-step the thread; because we are not at a breakpoint, since
it's been disabled, all other threads are continued during the
single-step. The second time we do this, we get a thread creation
event. GDB proceeds to lose track of the fact that it was
single-stepping, and resumes.
> >In other interesting notes, it looks like there is a (related?) problem
> >with target_thread_alive. The LWP I'm single-stepping in appears to be
> >marked as not alive about half the time. No idea what's up with that.
> >It appears to come from thread_db_thread_alive, not from
> >lin_lwp_thread_alive, which always succeeds.
> >
> >I can't reproduce the SIGSEGV now for some reason.
> >
>
> Have you managed to trace which test in thread_db_alive is returning false?
It may have been my imagination. Now all appears well.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer