Re: RFC: nptl threading patch for linux

["J. Johnston" <jjohnstn at redhat dot com>]

Daniel Jacobowitz wrote:
> On Sat, May 10, 2003 at 05:18:55PM -0400, Daniel Jacobowitz wrote:
>
> > On Fri, May 09, 2003 at 06:00:11PM -0400, Daniel Jacobowitz wrote:
> >
> > > On Thu, Apr 24, 2003 at 04:52:04PM -0400, J. Johnston wrote:
> > >
> > > > The following is the last part of my revised nptl patch that has
> > > > been broken up per Daniel J.'s suggestion.  There are no generated
> > > > files included in the patch.
> > >
> > > Well, this patch doesn't work for me :(  Using 2.5.69, since I don't
> > > have any of the Red Hat kernels available here at the moment.  It looks
> > > like GDB bellies up around the second thread creation.
> >
> > Sorry, I found the problem.  Configure was not finding tkill.  Entirely
> > a local problem; but how would you feel about something which set the
> > default number for __NR_tkill if __i386__?  Or has someone already
> > discouraged that approach?

Glad to hear this.

> > So:
> >
> >
> > >  - stop_wait_callback should be fixed to not be so dumb when this
> > >    happens.
> >
> > This one is still true.  Patch for another day.
> >
> >
> > >  - we need to figure out how we got into this mess.
> > >  - and why the SIGSTOP never showed up.
> >
> > But these are resolved.
> >
> >
> > I now get fairly good test results with your patch and NPTL; there are
> > some failures because of the vsyscall issue being currently discussed. 
> > Backtraces in linux-dp don't work because the threads are stopped in
> > the kernel page.
> >
> > I can also report that the kernel change I am testing to report thread
> > exits does not appear to cause your patch any problems.  Yay!  More on
> > that in a little while.

More good news.

> 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.

> This is timing sensitive.  It didn't show up with set debug
> lin-lwp/target both on.
>
> 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?

-- Jeff J.