From nobody@FreeBSD.org  Thu Dec 27 15:54:42 2001
Return-Path: <nobody@FreeBSD.org>
Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id F0E2237B417
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 27 Dec 2001 15:54:41 -0800 (PST)
Received: (from nobody@localhost)
	by freefall.freebsd.org (8.11.6/8.11.6) id fBRNsf696158;
	Thu, 27 Dec 2001 15:54:41 -0800 (PST)
	(envelope-from nobody)
Message-Id: <200112272354.fBRNsf696158@freefall.freebsd.org>
Date: Thu, 27 Dec 2001 15:54:41 -0800 (PST)
From: Kip Macy <kip_macy@yahoo.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: gdb does not handle pending signals correctly when single stepping
X-Send-Pr-Version: www-1.0

>Number:         33262
>Category:       gnu
>Synopsis:       gdb does not handle pending signals correctly when single stepping
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    mp
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Dec 27 16:00:10 PST 2001
>Closed-Date:    Sun Jul 31 12:03:32 GMT 2005
>Last-Modified:  Sun Jul 31 12:03:32 GMT 2005
>Originator:     Kip Macy
>Release:        4.4
>Organization:
Extended Solutions
>Environment:
FreeBSD raidclient1.lab.netapp.com 4.4-STABLE FreeBSD 4.4-STABLE #1: Tue Oct 23 22:43:28 PDT 2001     kmacy@raidclient1.lab.netapp.com:/usr/src/sys/compile/DEVELOPMENT  i386

>Description:
when a signal is pending (e.g. SIGALRM) at a breakpoint and the user
tries to single step - gdb will break at the signal handler in 
non-thread-code and at _sys_thread_sigprocmask in threaded code.
This makes it impossible to step through code that makes heavy use of
signals.

This is an example of the behaviour:
> gdb alr^Gmtest^M
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...
(gdb) b main
Breakpoint 1 at 0x8048666: file alrmtest.c, line 44.
(gdb) r
Starting program: /amd/ayr/vol/users2/home/kmacy/alrmtest 

Breakpoint 1, main () at alrmtest.c:44
44              sk_init_timer();
(gdb) n
45              while (1) {
(gdb) n

Program received signal SIGTRAP, Trace/breakpoint trap.
0x80485c0 in sk_millisecond_clock () at alrmtest.c:10
10      sk_millisecond_clock()
(gdb) n

Program received signal SIGTRAP, Trace/breakpoint trap.
main () at alrmtest.c:45
45              while (1) {
(gdb) n

Program received signal SIGTRAP, Trace/breakpoint trap.
0x80485c0 in sk_millisecond_clock () at alrmtest.c:10
10      sk_millisecond_clock()
(gdb) n

Program received signal SIGTRAP, Trace/breakpoint trap.
main () at alrmtest.c:45
45              while (1) {
(gdb) n

Program received signal SIGTRAP, Trace/breakpoint trap.
0x80485c0 in sk_millisecond_clock () at alrmtest.c:10
10      sk_millisecond_clock()
(gdb) n

Program received signal SIGTRAP, Trace/breakpoint trap.
main () at alrmtest.c:45
45              while (1) {

This is the correct behavior (same program on Linux or Solaris):

[kmacy@pris ~]$ gdb linux_alrmtest/alrmtest
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
(gdb) bt
No stack.
(gdb) b main
Breakpoint 1 at 0x804857e: file alrmtest.c, line 44.
(gdb) r
Starting program: /n/ayr/users2/kmacy/linux_alrmtest/alrmtest 

Breakpoint 1, main () at alrmtest.c:44
44              sk_init_timer();
(gdb) n
45              while (1) {
(gdb) n
50                      i = 0;
(gdb) n
54                      j = 0;
(gdb) n
55                      printf("milliseconds elapsed is %d\n", sk_msecs4);
(gdb) n
milliseconds elapsed is 40
56                      tmp_sleep(2);
(gdb) n
57              }
(gdb) n
45              while (1) {
(gdb) n
50                      i = 0;
(gdb) n
54                      j = 0;
(gdb) n
55                      printf("milliseconds elapsed is %d\n", sk_msecs4);
(gdb) n
milliseconds elapsed is 110
56                      tmp_sleep(2);
(gdb) n
57              }
(gdb) q

>How-To-Repeat:
single step through the while loop in alrmtest, the code follows:

#include <sys/types.h>
#include <sys/time.h>   /* for implementing system tic */
#include <signal.h>
#include <stdio.h>
#include <setjmp.h>

int sk_msecs4;
#define SK_MSEC_PER_TIC 10
void 
sk_millisecond_clock()
{
        extern int sk_msecs4;
        sk_msecs4 += SK_MSEC_PER_TIC; 
}

/*
 */
void 
sk_init_timer()
{
        struct itimerval tic;
        struct sigaction action;
        action.sa_handler = (void*) sk_millisecond_clock;
        action.sa_flags = SA_RESTART;
        sigemptyset(&action.sa_mask);
        sigaction(SIGALRM, &action, NULL);
        tic.it_interval.tv_sec = 0;
        tic.it_interval.tv_usec = SK_MSEC_PER_TIC * 1000;
        tic.it_value = tic.it_interval;
        setitimer(ITIMER_REAL, &tic, NULL);
}

unsigned int
tmp_sleep(unsigned int seconds) {
        struct timeval t;
        t.tv_sec = seconds;
        t.tv_usec = 0;
        select(0, NULL, NULL, NULL, &t);
}

int 
main() {
        int i, j;
        sk_init_timer();
        while (1) {
                
                /*  useless assignment to demonstrate lack of 
                 *  progress 
                 */
                i = 0;
                /*  useless assignment to demonstrate lack of 
                 *  progress 
                 */
                j = 0;
                printf("milliseconds elapsed is %d\n", sk_msecs4);
                tmp_sleep(2);
        }

}

>Fix:
Not sure yet, but the following indicates to me that 
freebsd_uthread_wait is not correct:
Breakpoint 6, wait_for_inferior () at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/infrun.c:1064
1064          registers_changed ();
(gdb) p w
$19 = {
  kind = TARGET_WAITKIND_STOPPED, 
  value = {
    integer = 0xe, 
    sig = TARGET_SIGNAL_ALRM, 
    related_pid = 0xe, 
    execd_pathname = 0xe <Error reading address 0xe: Bad address>, 
    syscall_id = 0xe
  }
}
(gdb) n
1066          if (target_wait_hook)
(gdb) p w
$20 = {
  kind = TARGET_WAITKIND_STOPPED, 
  value = {
    integer = 0xe, 
    sig = TARGET_SIGNAL_ALRM, 
    related_pid = 0xe, 
    execd_pathname = 0xe <Error reading address 0xe: Bad address>, 
    syscall_id = 0xe
  }
}
(gdb) n
1069            pid = target_wait (-1, &w);
(gdb) p w
$21 = {
  kind = TARGET_WAITKIND_STOPPED, 
  value = {
    integer = 0xe, 
    sig = TARGET_SIGNAL_ALRM, 
    related_pid = 0xe, 
    execd_pathname = 0xe <Error reading address 0xe: Bad address>, 
    syscall_id = 0xe
  }
}
(gdb) n
1074          thread_step_needed = 0;
(gdb) p w
$22 = {
  kind = TARGET_WAITKIND_STOPPED, 
  value = {
    integer = 0x5, 
    sig = TARGET_SIGNAL_TRAP, 
    related_pid = 0x5, 
    execd_pathname = 0x5 <Error reading address 0x5: Bad address>, 
    syscall_id = 0x5
  }
}

(gdb) p hoststatus
$50 = 0x57f
(gdb) p *ourstatus
$51 = {
  kind = TARGET_WAITKIND_STOPPED, 
  value = {
    integer = 0xe, 
    sig = TARGET_SIGNAL_ALRM, 
    related_pid = 0xe, 
    execd_pathname = 0xe <Error reading address 0xe: Bad address>, 
    syscall_id = 0xe
  }
}
(gdb) s
target_signal_from_host (hostsig=0x5) at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/target.c:1307
1307    {
(gdb) list
1302
1303    /* Convert host signal to our signals.  */
1304    enum target_signal
1305    target_signal_from_host (hostsig)
1306         int hostsig;
1307    {
1308      /* A switch statement would make sense but would require special kludges
1309         to deal with the cases where more than one signal has the same number.  */
1310
1311      if (hostsig == 0) return TARGET_SIGNAL_0;
(gdb) p hostsig
$52 = 0x5
(gdb) bt
#0  target_signal_from_host (hostsig=0x5) at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/target.c:1307
#1  0x80b9abb in store_waitstatus (ourstatus=0xbfbff538, hoststatus=0x57f) at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/target.c:1690
#2  0x808a268 in child_wait (pid=0xffffffff, ourstatus=0xbfbff538) at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/inftarg.c:247
#3  0x8080d60 in freebsd_uthread_wait (pid=0xffffffff, ourstatus=0xbfbff538) at /usr/src/gnu/usr.bin/binutils/gdb/freebsd-uthread.c:511
#4  0x8087bb4 in wait_for_inferior () at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/infrun.c:1069
#5  0x8087a09 in proceed (addr=0xffffffff, siggnal=TARGET_SIGNAL_DEFAULT, step=0x1) at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/infrun.c:922
#6  0x8085446 in step_1 (skip_subroutines=0x1, single_inst=0x0, count_string=0x0) at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/infcmd.c:416
#7  0x80852b1 in next_command (count_string=0x0, from_tty=0x1) at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/infcmd.c:332
#8  0x80bc317 in execute_command (p=0x8186001 "", from_tty=0x1) at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/top.c:1268
#9  0x80bc4a9 in command_loop () at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/top.c:1365
#10 0x8093665 in main (argc=0x1, argv=0xbfbff7ec) at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/main.c:636
#11 0x804a52d in _start (arguments=0xbfbff8f4 "/usr/libexec/elf/gdb") at /usr/src/lib/csu/i386-elf/crt1.c:96
(gdb) up
#1  0x80b9abb in store_waitstatus (ourstatus=0xbfbff538, hoststatus=0x57f) at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/target.c:1690
1690          ourstatus->value.sig = target_signal_from_host (WSTOPSIG (hoststatus));
(gdb) finish
Run till exit from #1  0x80b9abb in store_waitstatus (ourstatus=0xbfbff538, hoststatus=0x57f) at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/target.c:1690
child_wait (pid=0xffffffff, ourstatus=0xbfbff538) at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/inftarg.c:248
248       return pid;
(gdb) list
243     /* hack for thread testing */
244           } while( (pid != inferior_pid) && not_same_real_pid );
245     /*##*/
246
247       store_waitstatus (ourstatus, status);
248       return pid;
249     }
250     #endif /* CHILD_WAIT */
251
252     #if !defined(CHILD_POST_WAIT)
(gdb) p *ourstatus
$53 = {
  kind = TARGET_WAITKIND_STOPPED, 
  value = {
    integer = 0x5, 
    sig = TARGET_SIGNAL_TRAP, 
    related_pid = 0x5, 
    execd_pathname = 0x5 <Error reading address 0x5: Bad address>, 
    syscall_id = 0x5
  }
}
(gdb) 


>Release-Note:
>Audit-Trail:

From: k Macy <kip_macy@yahoo.com>
To: Donald Gillies <dgillies@graviton.com>,
	freebsd-gnats-submit@FreeBSD.org, freebsd-stable@freebsd.org,
	freebsd-hackers@freebsd.org
Cc: kip_macy@yahoo.com
Subject: ptrace bug was Re: gnu/33262: gdb does not handle pending signals correctly when single stepping
Date: Thu, 3 Jan 2002 23:45:07 -0800 (PST)

 Not to mention that SIGVTALRM is already used by 
 the thread library (although I would hope that
 _thread_sys_sigaction is smart enough to handle
 that case). I've stepped through the GDB
 code on both 4.18 and 5.1. On 5.1 I found the
 following in i386fbsd-nat.c:
 
 void
 child_resume (ptid_t ptid, int step, enum
 target_signal signal)
 {
   pid_t pid = ptid_get_pid (ptid);
   int request = PT_STEP;
 
   if (pid == -1)
     /* Resume all threads.  This only gets used in the
 non-threaded
        case, where "resume all threads" and "resume
 inferior_ptid" are
        the same.  */
     pid = ptid_get_pid (inferior_ptid);
 
   if (!step)
     {
       unsigned int eflags;
 
       /* Workaround for a bug in FreeBSD.  Make sure
 that the trace
          flag is off when doing a continue.  There is
 a code path
          through the kernel which leaves the flag set
 when it should
          have been cleared.  If a process has a signal
 pending (such
          as SIGALRM) and we do a PT_STEP, the process
 never really has
          a chance to run because the kernel needs to
 notify the
          debugger that a signal is being sent. 
 Therefore, the process
          never goes through the kernel's trap()
 function which would
          normally clear it.  */
 
       eflags = read_register (PS_REGNUM);
       if (eflags & 0x0100)
         write_register (PS_REGNUM, eflags & ~0x0100);
 
       request = PT_CONTINUE;
     }
 
 It is pretty clear that: 
 a) this does not deal with the case of step or next
 b) this does not work in the case of continue often
    times because step will be set to 1
 and hence, this code does _not_ work around the bug.
 
 This appears to be less of a GDB bug and more of a
 kernel bug in ptrace.
 
                     -Kip
 
 --- Donald Gillies <dgillies@graviton.com> wrote:
 > I think this bug may be associated only with the
 > SIGALRM signal.  When I
 > convert my code to use SIGVTALRM, the problem goes
 > away.  Unfortunately,
 > SIGVTALRM does not do exactly 
 > what I am looking for !!
 >  
 > # gdb 5.10
 > # $FreeBSD: src/COPYRIGHT,v 1.4 1999/09/05 21:33:47
 > obrien Exp $
 > #       @(#)COPYRIGHT   8.2 (Berkeley) 3/21/94
 >  
 > 
 >  
 
 
 __________________________________________________
 Do You Yahoo!?
 Send your FREE holiday greetings online!
 http://greetings.yahoo.com

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: Sat, 5 Jan 2002 18:59:00 +1100 (EST)

 On Thu, 3 Jan 2002, k Macy wrote:
 
 >  Not to mention that SIGVTALRM is already used by
 >  the thread library (although I would hope that
 >  _thread_sys_sigaction is smart enough to handle
 >  that case). I've stepped through the GDB
 >  code on both 4.18 and 5.1. On 5.1 I found the
 >  following in i386fbsd-nat.c:
 >
 >  void
 >  child_resume (ptid_t ptid, int step, enum
 >  target_signal signal)
 >  {
 >    pid_t pid = ptid_get_pid (ptid);
 >    int request = PT_STEP;
 >
 >    if (pid == -1)
 >      /* Resume all threads.  This only gets used in the
 >  non-threaded
 >         case, where "resume all threads" and "resume
 >  inferior_ptid" are
 >         the same.  */
 >      pid = ptid_get_pid (inferior_ptid);
 >
 >    if (!step)
 >      {
 >        unsigned int eflags;
 >
 >        /* Workaround for a bug in FreeBSD.  Make sure
 >  that the trace
 >           flag is off when doing a continue.  There is
 >  a code path
 >           through the kernel which leaves the flag set
 >  when it should
 >           have been cleared.  If a process has a signal
 >  pending (such
 >           as SIGALRM) and we do a PT_STEP, the process
 >  never really has
 >           a chance to run because the kernel needs to
 >  notify the
 >           debugger that a signal is being sent.
 >  Therefore, the process
 >           never goes through the kernel's trap()
 >  function which would
 >           normally clear it.  */
 >
 >        eflags = read_register (PS_REGNUM);
 >        if (eflags & 0x0100)
 >          write_register (PS_REGNUM, eflags & ~0x0100);
 >
 >        request = PT_CONTINUE;
 >      }
 >
 >  It is pretty clear that:
 >  a) this does not deal with the case of step or next
 >  b) this does not work in the case of continue often
 >     times because step will be set to 1
 >  and hence, this code does _not_ work around the bug.
 >
 >  This appears to be less of a GDB bug and more of a
 >  kernel bug in ptrace.
 
 There are at least 3 bugs, and the enclosed patches fix 2 of them.
 
 (1) sendsig() didn't clear the trace flag.  This was the primary cause
     of the misbehaviour reported in the PR.  When gdb restarts the
     process, there is a SIGALRM pending unless you type _very_ fast.
     gdb sets the trace flag before restarting the process, and the
     bug causes the signal handler to inherit the trace flag, so the
     signal handler stops after its first instruction.
 
 (2) syscall() sometimes generates a SIGTRAP, and got it wrong.  When
     the trace flag is set for an instruction that traps to the kernel
     for a syscall, syscall() wants to generate a SIGTRAP for the first
     instruction after the syscall returns instead of 1 later.  It got
     this wrong by checking the new trace flag instead of the old one.
     This bites when the sigreturn() is from a signal handler and the
     signal handler interrupted an instruction that is being traced.
     With the fix for (1), the trace flag will be off until the signal
     handler calls sigreturn().  Bug (2) causes generation of a SIGTRAP
     for the instruction that is being traced before that instruction
     can be started, and this trap repeats unless you type faster than
     the signals arrive (or type ahead).
 
 (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.
 
 %%%
 Index: machdep.c
 ===================================================================
 RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v
 retrieving revision 1.486
 diff -u -2 -r1.486 machdep.c
 --- machdep.c	20 Dec 2001 23:48:29 -0000	1.486
 +++ machdep.c	5 Jan 2002 07:18:13 -0000
 @@ -402,5 +402,5 @@
 
  		/* See sendsig() for comments. */
 -		tf->tf_eflags &= ~(PSL_VM | PSL_NT | PSL_T | PSL_VIF | PSL_VIP);
 +		tf->tf_eflags &= ~(PSL_VM | PSL_NT | PSL_VIF | PSL_VIP);
  	}
 
 @@ -418,4 +418,5 @@
  	regs->tf_esp = (int)fp;
  	regs->tf_eip = PS_STRINGS - szosigcode;
 +	regs->tf_eflags &= ~PSL_T;
  	regs->tf_cs = _ucodesel;
  	regs->tf_ds = _udatasel;
 @@ -546,8 +547,4 @@
 
  		/*
 -		 * We should never have PSL_T set when returning from vm86
 -		 * mode.  It may be set here if we deliver a signal before
 -		 * getting to vm86 mode, so turn it off.
 -		 *
  		 * Clear PSL_NT to inhibit T_TSSFLT faults on return from
  		 * syscalls made by the signal handler.  This just avoids
 @@ -556,5 +553,5 @@
  		 * almost legitimately in probes for old cpu types.
  		 */
 -		tf->tf_eflags &= ~(PSL_VM | PSL_NT | PSL_T | PSL_VIF | PSL_VIP);
 +		tf->tf_eflags &= ~(PSL_VM | PSL_NT | PSL_VIF | PSL_VIP);
  	}
 
 @@ -572,4 +569,5 @@
  	regs->tf_esp = (int)sfp;
  	regs->tf_eip = PS_STRINGS - *(p->p_sysent->sv_szsigcode);
 +	regs->tf_eflags &= ~PSL_T;
  	regs->tf_cs = _ucodesel;
  	regs->tf_ds = _udatasel;
 Index: trap.c
 ===================================================================
 RCS file: /home/ncvs/src/sys/i386/i386/trap.c,v
 retrieving revision 1.210
 diff -u -2 -r1.210 trap.c
 --- trap.c	30 Dec 2001 19:43:59 -0000	1.210
 +++ trap.c	5 Jan 2002 06:19:12 -0000
 @@ -934,4 +934,5 @@
  	struct thread *td = curthread;
  	struct proc *p = td->td_proc;
 +	register_t orig_tf_eflags;
  	u_int sticks;
  	int error;
 @@ -951,4 +952,5 @@
  #endif
 
 +	orig_tf_eflags = frame.tf_eflags;
  	sticks = td->td_kse->ke_sticks;
  	td->td_frame = &frame;
 @@ -1066,5 +1068,5 @@
  	 * Traced syscall.
  	 */
 -	if ((frame.tf_eflags & PSL_T) && !(frame.tf_eflags & PSL_VM)) {
 +	if ((orig_tf_eflags & PSL_T) && !(orig_tf_eflags & PSL_VM)) {
  		frame.tf_eflags &= ~PSL_T;
  		trapsignal(p, SIGTRAP, 0);
 %%%
 
 Bruce
 

From: k Macy <kip_macy@yahoo.com>
To: Bruce Evans <bde@zeta.org.au>
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: Sun, 6 Jan 2002 16:46:57 -0800 (PST)

 When can we get your fixes committed? Using gdb 5.1
 (see below) they appear to completely solve the 
 problem.
 
 > (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,
 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.
 
 a brief excerpt from 5.1:
 (gdb) n
 60                      i = 0;
 (gdb) n
 62                      j = 0;
 (gdb) 
 63                      printf("milliseconds elapsed
 is %d\n", sk_msecs4);
 (gdb) 
 milliseconds elapsed is 243
 64                      test_sleep(2);
 (gdb) 
 65              }
 (gdb) 
 60                      i = 0;
 (gdb) 
 62                      j = 0;
 (gdb) 
 63                      printf("milliseconds elapsed
 is %d\n", sk_msecs4);
 
 
 __________________________________________________
 Do You Yahoo!?
 Send FREE video emails in Yahoo! Mail!
 http://promo.yahoo.com/videomail/

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
 
Responsible-Changed-From-To: freebsd-bugs->mp 
Responsible-Changed-By: sheldonh 
Responsible-Changed-When: Wed Jan 30 05:06:03 PST 2002 
Responsible-Changed-Why:  
Over to maintainer. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=33262 
State-Changed-From-To: open->patched 
State-Changed-By: mp 
State-Changed-When: Sat Jun 29 18:17:06 PDT 2002 
State-Changed-Why:  
This is fixed in -current with the import of gdb-5.2. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=33262 

From: Matteo Riondato <rionda@gufi.org>
To: Gnats PR Database <freebsd-gnats-submit@freebsd.org>
Cc: mp@freebsd.org
Subject: Re: gnu/33262: gdb does not handle pending signals correctly when single stepping
Date: Sun, 10 Apr 2005 19:16:21 +0200

 --/zLL6W406Aotuby1
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 This was fixed on RELENG_5 too.
 I don't think that there will be a future import of gdb to RELENG_4,
 so this PR can be closed.
 Best Regards
 --=20
 Rionda aka Matteo Riondato
 Disinformato per default
 G.U.F.I. Staff Member (http://www.gufi.org)
 FreeSBIE Developer (http://www.freesbie.org)
 
 --/zLL6W406Aotuby1
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.0 (FreeBSD)
 
 iD8DBQFCWV9l2Mp4pR7Fa+wRAq76AJ42VBZiP11KqdXavevorsJvRFdOXACgtoNB
 eJ6YnnqentAITYqMjFVXi6g=
 =giVW
 -----END PGP SIGNATURE-----
 
 --/zLL6W406Aotuby1--
State-Changed-From-To: patched->closed 
State-Changed-By: matteo 
State-Changed-When: Sun Jul 31 12:03:03 GMT 2005 
State-Changed-Why:  
Fixed and MFCed 

http://www.freebsd.org/cgi/query-pr.cgi?pr=33262 
>Unformatted:
