Date: Wed, 7 Aug 2002 17:39:42 -0700 (PDT) From: David Xu <bsddiy@yahoo.com> To: Christian Weisgerber <naddy@mips.inka.de> Cc: freebsd-current <freebsd-current@freebsd.org>, Julian Elischer <julian@elischer.org> Subject: Re: Signals/jobs weirdness? Message-ID: <20020808003942.96051.qmail@web20908.mail.yahoo.com>
next in thread | raw e-mail | index | archive | help
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" <naddy@mips.inka.de> To: <freebsd-current@freebsd.org> Sent: Thursday, August 08, 2002 1:48 AM Subject: Re: Signals/jobs weirdness? > Christian Weisgerber <naddy@mips.inka.de> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020808003942.96051.qmail>