Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 7 Jan 2002 18:20:02 -0800 (PST)
From:      Bruce Evans <bde@zeta.org.au>
To:        freebsd-bugs@FreeBSD.org
Subject:   Re: ptrace bug was Re: gnu/33262: gdb does not handle pending signals correctly when single stepping
Message-ID:  <200201080220.g082K2m07605@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR gnu/33262; it has been noted by GNATS.

From: Bruce Evans <bde@zeta.org.au>
To: k Macy <kip_macy@yahoo.com>
Cc: <freebsd-gnats-submit@FreeBSD.ORG>
Subject: Re: ptrace bug was Re: gnu/33262: gdb does not handle pending signals
 correctly when single stepping
Date: Tue, 8 Jan 2002 13:11:53 +1100 (EST)

 On Sun, 6 Jan 2002, k Macy wrote:
 
 > When can we get your fixes committed? Using gdb 5.1
 > (see below) they appear to completely solve the
 > problem.
 
 I'll try to get them in 4.5.  Not sure if there is time.
 
 > > (3) "stepi" seems to work perfectly with these fixes
 > > for (1) and (2), but
 > >     "next" rarely works.  gdb apparently gets
 > > confused about the temporary
 > >     breakpoints that it sets for "next".  It gets
 > > SIGTRAPs for them and
 > >     should remove them and continue with single
 > > steps, but it leaves them
 > >     in and spins getting SIGTRAPs (and SIGALRMs in
 > > the test program).  This
 > >     is with gdb-4.18.
 >
 > My experience with -CURRENT installed from today's
 > snapshot:
 > FreeBSD weizen.extendedsolutions.com
 > 5.0-20020106-CURRENT FreeBSD 5.0-20020106-CURRENT #1:
 > Sun Jan  6 16:22:13 PST 2002
 > root@goober.extendedsolutions:/usr/src/sys/i386/compile/HADES
 >  i386
 >
 > is that with 4.18 next works until the sleep, but
 > the sleep never returns. With 5.1 it works correctly,
 
 Usually the same here, except I don't have 5.1.  The first sleep
 sometimes works, but usually not, and subsequent sleeps almost never
 work.  strace and debugging gdb show the SIGTRAPS mentioned above.  I
 think the failure on the syscall for the sleep is not significant.
 Stepping into or over the sleep function just gives more races to
 lose.
 
 > so as soon as FreeBSD upgrades to 5.1 one we can mark
 > the bug fixed. If by lending a hand I can accelerate
 > that process I would be happy to do the work, e.g.
 > migrating freebsd-uthread.c, the kernel core debug
 > functionality etc.
 
 I saw the same non-failure as you under Linux.  I only have an old
 Linux setup with gdb-4.16, so the final bug might still be in the
 kernel and the fix in gdb-5.1.  The most useful thing you could do
 might be to isolate the fix in 5.1.  The one that you quoted seemed
 to be mainly for the trace flag non-clearing bug.  The quote helped me
 find the bug.
 
 Bruce
 

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200201080220.g082K2m07605>