Date: Wed, 7 Aug 2002 17:48:14 +0000 (UTC) From: naddy@mips.inka.de (Christian Weisgerber) To: freebsd-current@freebsd.org Subject: Re: Signals/jobs weirdness? Message-ID: <airmgu$30e2$1@kemoauc.mips.inka.de> References: <aipjlf$51b$1@kemoauc.mips.inka.de> <Pine.BSF.4.21.0208061828020.65715-100000@InterJet.elischer.org> <aiqtb3$m8q$1@kemoauc.mips.inka.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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
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?airmgu$30e2$1>