From owner-freebsd-bugs Fri Aug 1 05:17:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA16941 for bugs-outgoing; Fri, 1 Aug 1997 05:17:50 -0700 (PDT) Received: from kanin.arnes.si (kanin.arnes.si [193.2.1.66]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id FAA16934 for ; Fri, 1 Aug 1997 05:17:47 -0700 (PDT) Received: from irc.arnes.si by kanin.arnes.si with SMTP using DNS (PP) id <00310-0@kanin.arnes.si>; Fri, 1 Aug 1997 14:17:25 +0200 Received: by tosc.arnes.si with SMTP id <4308-143>; Fri, 1 Aug 1997 14:17:18 +0100 X-Mailer: exmh version 1.6.9 8/22/96 To: freebsd-bugs@FreeBSD.ORG Subject: possible bug in ptrace(2) - PT_DETACH Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 Aug 1997 14:17:04 +0200 From: Uros Juvan Message-Id: <97Aug1.141718mest.4308-143+229@tosc.arnes.si> Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Look Forwarded Mesage below: ------- Forwarded Message Received: from kanin.arnes.si ([193.2.1.66]) by tosc.arnes.si with SMTP id <4308-143>; Fri, 1 Aug 1997 11:34:40 +0100 Received: from revenue.regent.e-technik.tu-muenchen.de by kanin.arnes.si with SMTP using DNS (PP) id <19393-0@kanin.arnes.si>; Fri, 1 Aug 1997 11:33:56 +0200 Received: from red.regent.e-technik.tu-muenchen.de (pes@red.regent.e-technik.tu-muenchen.de [129.187.231.159]) by revenue.regent.e-technik.tu-muenchen.de (8.8.5/8.6.9) with ESMTP id LAA08988 ; Fri, 1 Aug 1997 11:33:47 +0200 From: "Peter.Schauer" Received: (pes@localhost) by red.regent.e-technik.tu-muenchen.de (8.8.5/8.6.9) id LAA16690 ; Fri, 1 Aug 1997 11:33:46 +0200 Message-Id: <199708010933.LAA16690@red.regent.e-technik.tu-muenchen.de> Subject: Re: gdb and signals To: uros.juvan@arnes.si (Uros Juvan) Date: Fri, 1 Aug 97 11:33:45 MET DST Cc: shebs@cygnus.com In-Reply-To: <97Aug1.095519mest.4308-143+225@tosc.arnes.si>; from "Uros Juvan" at Aug 1, 97 9:55 am X-Mailer: ELM [version 2.3 PL6] This looks like a bug in the freebsd kernel, GDB behaves as expected when I tried the example under SunOs 4.1. The following GDB code is executed when the detach command is issued: int siggnal = 0; if (from_tty) { char *exec_file = get_exec_file (0); if (exec_file == 0) exec_file = ""; printf_unfiltered ("Detaching from program: %s %s\n", exec_file, target_pid_to_str (inferior_pid)); gdb_flush (gdb_stdout); } if (args) siggnal = atoi (args); detach (siggnal); and detach is: errno = 0; ptrace (PT_DETACH, inferior_pid, (PTRACE_ARG3_TYPE) 1, signal); if (errno) perror_with_name ("ptrace"); Traditionally passing signal 0 to PT_DETACH means to cancel the current signal, but it seems that freebsd doesn't honor the request. > Hello. > > Is this kind of behavio a bug or a feature: > > test.c program: > ---------------- > #include > #include > > main() > { > while (1) { > sleep(1); > } > } > ----------------- > > Then I run this program in background: > # ./test & > [1] 8407 > > Then I run gdb > # gdb > GDB is free software and you are welcome to 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. > GDB 4.16 (i386-unknown-freebsd), Copyright 1996 Free Software Foundation, Inc. > (gdb) attach 8407 > Attaching to process 8407 > 0x804d853 in ?? () > (gdb) info handle > Signal Stop Print Pass to program Description > > SIGHUP Yes Yes Yes Hangup > SIGINT Yes Yes No Interrupt > . > . > . > (gdb) c > Continuing. > ^C > Program received signal SIGINT, Interrupt. > 0x804d853 in ?? () > (gdb) detach > Detaching from program: process 8407 > (gdb) quit > [1]+ Interrupt ./test > # jobs > # > > ------------------------------------------------------------------------------- > As far as I read in info pages this should not happen. gdb should not deliver > SIGINT to process after it has been detached. > > With regards, > Uros Juvan > ARNES - -- Peter Schauer pes@regent.e-technik.tu-muenchen.de ------- End of Forwarded Message I run FreeBSD V2.2.1 and my sys_process.c (PT_DETACH) part looks like this: ---------- case PT_DETACH: if ((unsigned)uap->data >= NSIG) return EINVAL; PHOLD(p); if (uap->req == PT_STEP) { if ((error = ptrace_single_step (p))) { PRELE(p); return error; } } if (uap->addr != (caddr_t)1) { fill_eproc (p, &p->p_addr->u_kproc.kp_eproc); if ((error = ptrace_set_pc (p, (u_int)uap->addr))) { PRELE(p); return error; } } PRELE(p); if (uap->req == PT_DETACH) { /* reset process parent */ if (p->p_oppid != p->p_pptr->p_pid) { struct proc *pp; pp = pfind(p->p_oppid); proc_reparent(p, pp ? pp : initproc); } p->p_flag &= ~(P_TRACED | P_WAITED); p->p_oppid = 0; /* should we send SIGCHLD? */ <- that's what I'm worried about... } ---------- With regards, Uros Juvan ARNES