From owner-freebsd-current Mon Apr 15 01:21:07 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA20002 for current-outgoing; Mon, 15 Apr 1996 01:21:07 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA19955 Mon, 15 Apr 1996 01:20:55 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA15525; Mon, 15 Apr 1996 10:20:48 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id KAA14323; Mon, 15 Apr 1996 10:20:48 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id JAA11351; Mon, 15 Apr 1996 09:53:15 +0200 (MET DST) From: J Wunsch Message-Id: <199604150753.JAA11351@uriah.heep.sax.de> Subject: Re: Interesting bash bug - anyone else see this? To: ports@FreeBSD.org Date: Mon, 15 Apr 1996 09:53:13 +0200 (MET DST) Cc: freebsd-current@FreeBSD.org (FreeBSD-current users) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199604150138.SAA16211@time.cdrom.com> from "Jordan K. Hubbard" at Apr 14, 96 06:38:25 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Jordan K. Hubbard wrote: > > I just noticed it, myself. It doesn't happen in sh or csh, so it's > definitely one for -bash and -current (if not also -stable; I dunno!). > > > root@reason-> ls -lt | more > ^Z > [2]+ Done ls -lt | more > root@reason-> fg > ls -lt | more > Broken pipe > > Bug #1: Upon suspending, bash erroneously reports the background job's status > as "Done", not "Suspended" > > Bug #2: Upon resuming, we're hosed - the pipe breaks. I can reproduce it. Depending upon how quickly i pressed ^Z, i could even get bash into a totally hosed state, the ^Z has been displayed, but ``nichts geht mehr''. Only a SIGCONT from a different window helped. It seems that bash sends the SIGSTOP to each process in turn instead of the entire process group of the pipeline: 107 11252 270 0 10 0 628 884 wait S p3 0:00.30 bash 107 11261 11252 0 28 0 352 152 - T+ p3 0:00.03 ls -lt 107 11262 11252 1 -6 0 204 512 piperd S+ p3 0:00.08 more You'll note that `more' hasn't got a stop signal, it's running and waiting for input from the pipe. This is your case: 107 11252 270 1 10 0 628 700 wait S p3 0:00.43 bash 107 11267 11252 1 28 0 384 232 - T p3 0:00.07 ls -lt The `ls' has been stopped, but `more' is already dead. (That's why bash is reporting it as `Done'.) I could reproduce the deadlock situation with /bin/sh as well. The symptoms are identical (ls is in the `T' state, more is `S'). To the contrary, this is how tcsh arranges for it: j 270 269 270 7fdaa0 0 Ss p3 0:12.53 -tcsh (tcsh) j 11330 270 11330 7fdaa0 2 T p3 0:00.02 -tcsh (tcsh) j 11331 270 11330 7fdaa0 2 T p3 0:00.03 more j 11332 11330 11330 7fdaa0 2 T p3 0:00.02 ls -CF -lt PID 270 is my interactive shell, PID (and PGID) 11330 is the pipeline. Unlike with the Bourne-alike shells, tcsh spent an entire subshell to the pipeline, and this one has got the stop signal. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)