From owner-freebsd-current Wed Aug 7 17:29:30 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0050B37B400 for ; Wed, 7 Aug 2002 17:29:23 -0700 (PDT) Received: from web20904.mail.yahoo.com (web20904.mail.yahoo.com [216.136.226.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 9B20B43E6E for ; Wed, 7 Aug 2002 17:29:22 -0700 (PDT) (envelope-from bsddiy@yahoo.com) Message-ID: <20020808002922.39049.qmail@web20904.mail.yahoo.com> Received: from [210.83.128.34] by web20904.mail.yahoo.com via HTTP; Wed, 07 Aug 2002 17:29:22 PDT Date: Wed, 7 Aug 2002 17:29:22 -0700 (PDT) From: David Xu To: Christian Weisgerber Cc: freebsd-current , Julian Elischer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Does this patch work for you? David Xu --- proc.h Thu Aug 8 08:07:29 2002 +++ proc.h.new Thu Aug 8 08:08:48 2002 @@ -563,9 +563,9 @@ #define P_CONTINUED 0x10000 /* Proc has continued from a stopped state. */ /* flags that control how threads may be suspended for some reason */ -#define P_STOPPED_SGNL 0x10000 /* Stopped due to SIGSTOP/SIGTSTP */ -#define P_STOPPED_TRACE 0x20000 /* Stopped because of tracing */ -#define P_STOPPED_SNGL 0x40000 /* Only one thread can continue (not to user) */ +#define P_STOPPED_SGNL 0x20000 /* Stopped due to SIGSTOP/SIGTSTP */ +#define P_STOPPED_TRACE 0x40000 /* Stopped because of tracing */ +#define P_STOPPED_SNGL 0x80000 /* Only one thread can continue (not to user) */ #define P_SINGLE_EXIT 0x00400 /* Threads suspending should exit, not wait */ #define P_TRACED 0x00800 /* Debugged process being traced. */ #define P_STOPPED (P_STOPPED_SGNL|P_STOPPED_SNGL|P_STOPPED_TRACE) ----- Original Message ----- From: "Christian Weisgerber" To: Sent: Thursday, August 08, 2002 1:48 AM Subject: Re: Signals/jobs weirdness? > Christian Weisgerber wrote: > > > It's a bash problem. > > > > $ less IrcLog > > ... > > ^Z > > [1]+ Stopped less IrcLog > > $ jobs > > [1]+ Running less IrcLog & > > On the other hand, I wonder whether there isn't something strange > going on. I'll provide a bit of kdump output interspersed with > comments below. > > 96402 bash NAMI "/usr/bin/less" > 96402 bash RET stat 0 > 96402 bash CALL sigprocmask(0x1,0x11fff380,0x11fff390) > 96402 bash RET sigprocmask 0 > 96402 bash CALL fork > 96402 bash RET fork 96407/0x17897 > 96402 bash CALL setpgid(0x17897,0x17897) > 96402 bash RET setpgid 0 > 96402 bash CALL sigprocmask(0x3,0x11fff390,0) > 96402 bash RET sigprocmask 0 > 96402 bash CALL sigprocmask(0x1,0x11fff4a0,0x11fff4b0) > 96402 bash RET sigprocmask 0 > 96402 bash CALL sigprocmask(0x1,0x11fff450,0x11fff460) > 96402 bash RET sigprocmask 0 > 96402 bash CALL ioctl(0xff,TIOCSPGRP,0x11fff420) > 96402 bash RET ioctl 0 > 96402 bash CALL sigprocmask(0x3,0x11fff460,0) > 96402 bash RET sigprocmask 0 > 96402 bash CALL sigprocmask(0x3,0x11fff4b0,0) > 96402 bash RET sigprocmask 0 > 96402 bash CALL sigprocmask(0x1,0x11fff498,0x11fff4a8) > 96402 bash RET sigprocmask 0 > 96402 bash CALL wait4(0xffffffffffffffff,0x11fff440,0x6,0) > > bash synchronously starts a foreground job. > > 96407 bash RET fork 0 > ... > 96407 bash CALL execve(0x12016dbd0,0x120169060,0x12016b000) > 96407 bash NAMI "/usr/bin/less" > 96407 bash NAMI "/usr/libexec/ld-elf.so.1" > 96407 less RET execve 0 > > The child, an instance of less, is running. > > ... > 96407 less CALL sigaction(0x16,0x11fff5a0,0x11fff5c0) > 96407 less RET sigaction 0 > 96407 less CALL sigaction(0x12,0x11fff5a0,0x11fff5c0) > 96407 less RET sigaction 0 > 96407 less CALL getpid > 96407 less RET getpid 96407/0x17897 > 96407 less CALL kill(0x17897,0x12) > > I press ^Z. less catches SIGTSTP, does some cleanup, and suspends > itself with another SIGTSTP. > > 96402 bash RET wait4 96407/0x17897 > 96402 bash CALL sigprocmask(0x1,0x11fff3c0,0x11fff3d0) > 96402 bash RET sigprocmask 0 > 96402 bash CALL sigprocmask(0x3,0x11fff3d0,0) > 96402 bash RET sigprocmask 0 > 96402 bash CALL sigprocmask(0x1,0x11fff3c0,0x11fff3d0) > 96402 bash RET sigprocmask 0 > 96402 bash CALL sigprocmask(0x3,0x11fff3d0,0) > 96402 bash RET sigprocmask 0 > 96402 bash CALL sigprocmask(0x1,0x11fff430,0x11fff440) > 96402 bash RET sigprocmask 0 > 96402 bash CALL ioctl(0xff,TIOCSPGRP,0x11fff400) > 96402 bash RET ioctl 0 > 96402 bash CALL sigprocmask(0x3,0x11fff440,0) > 96402 bash RET sigprocmask 0 > 96402 bash CALL ioctl(0xff,TIOCSETAW,0x12015197c) > 96402 bash RET ioctl 0 > 96402 bash CALL write(0x2,0x12016e000,0x1) > 96402 bash GIO fd 2 wrote 1 byte > " > " > 96402 bash RET write 1 > 96402 bash CALL write(0x2,0x12016e000,0x2e) > 96402 bash GIO fd 2 wrote 46 bytes > "[1]+ Stopped less nail.patch > " > 96402 bash RET write 46/0x2e > > bash returns from wait4(), gets the job's status, and prints that the > job is stopped. > > 96402 bash CALL sigprocmask(0x3,0x11fff4a8,0) > 96402 bash RET sigprocmask 0 > 96402 bash PSIG SIGCHLD caught handler=0x120023dd0 mask=0x0 code=0x0 > 96402 bash CALL wait4(0xffffffffffffffff,0x11fff0f0,0x7,0) > > bash re-enables SIGCHLD, promptly receives one, polls for status > change notifications... > > 96402 bash RET wait4 96407/0x17897 > 96402 bash CALL wait4(0xffffffffffffffff,0x11fff0f0,0x7,0) > 96402 bash RET wait4 0 > > ... and receives a notification for the less process. What's up with > this? bash already got the information that less was stopped from > its synchronous wait4() above, didn't it? So why does wait4() > deliver another status change for PID 96407. > > And the good part, which you can't see in the trace, is what wait4() > reports as process status. I attached gdb to a running bash and > single-stepped that part. bash checks the status with WIFCONTINUED(), > which returns success. status is 0x13. > > Why does the kernel report to bash that the child received a SIGCONT? > > The rest of the problem follows from this. bash re-classifies the > job as running and does not send a SIGCONT of its own when the job > is fg'ed again. > > -- > Christian "naddy" Weisgerber naddy@mips.inka.de __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message