From owner-freebsd-bugs Mon Jan 7 18:20: 6 2002 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 8FCBC37B405 for ; Mon, 7 Jan 2002 18:20:02 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g082K2m07605; Mon, 7 Jan 2002 18:20:02 -0800 (PST) (envelope-from gnats) Date: Mon, 7 Jan 2002 18:20:02 -0800 (PST) Message-Id: <200201080220.g082K2m07605@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Bruce Evans Subject: Re: ptrace bug was Re: gnu/33262: gdb does not handle pending signals correctly when single stepping Reply-To: Bruce Evans Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR gnu/33262; it has been noted by GNATS. From: Bruce Evans To: k Macy Cc: 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