From owner-freebsd-current Wed Aug 7 11:31:13 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 9FB4C37B400 for ; Wed, 7 Aug 2002 11:31:04 -0700 (PDT) Received: from mail.inka.de (quechua.inka.de [212.227.14.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5155343E7B for ; Wed, 7 Aug 2002 11:31:03 -0700 (PDT) (envelope-from mailnull@mips.inka.de) Received: from kemoauc.mips.inka.de (uucp@) by mail.inka.de with local-bsmtp id 17cVaI-0000qd-00; Wed, 7 Aug 2002 20:31:02 +0200 Received: from kemoauc.mips.inka.de (localhost [127.0.0.1]) by kemoauc.mips.inka.de (8.12.5/8.12.5) with ESMTP id g77HmFMI098764 for ; Wed, 7 Aug 2002 19:48:15 +0200 (CEST) (envelope-from mailnull@localhost.mips.inka.de) Received: (from mailnull@localhost) by kemoauc.mips.inka.de (8.12.5/8.12.5/Submit) id g77HmFdn098763 for freebsd-current@freebsd.org; Wed, 7 Aug 2002 19:48:15 +0200 (CEST) From: naddy@mips.inka.de (Christian Weisgerber) Subject: Re: Signals/jobs weirdness? Date: Wed, 7 Aug 2002 17:48:14 +0000 (UTC) Message-ID: References: Originator: naddy@mips.inka.de (Christian Weisgerber) To: freebsd-current@freebsd.org 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 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message