From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4115 invoked by alias); 17 Aug 2003 20:49:30 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 4108 invoked from network); 17 Aug 2003 20:49:29 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 17 Aug 2003 20:49:29 -0000 Received: from drow by nevyn.them.org with local (Exim 4.20 #1 (Debian)) id 19oUSt-0002zz-Jv; Sun, 17 Aug 2003 16:49:27 -0400 Date: Sun, 17 Aug 2003 20:49:00 -0000 From: Daniel Jacobowitz To: "J. Johnston" Cc: gdb-patches@sources.redhat.com, roland@redhat.com Subject: Re: RFC: nptl threading patch for linux Message-ID: <20030817204927.GA11300@nevyn.them.org> Mail-Followup-To: "J. Johnston" , gdb-patches@sources.redhat.com, roland@redhat.com References: <3EA84E74.3010101@redhat.com> <20030509220011.GA22383@nevyn.them.org> <20030510211855.GA4312@nevyn.them.org> <20030510215939.GA4907@nevyn.them.org> <3EBFF7C3.2000905@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EBFF7C3.2000905@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-08/txt/msg00276.txt.bz2 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