Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 7 Aug 2002 23:10:51 -0700 (PDT)
From:      Julian Elischer <julian@elischer.org>
To:        David Xu <bsddiy@yahoo.com>
Cc:        Christian Weisgerber <naddy@mips.inka.de>, freebsd-current <freebsd-current@freebsd.org>
Subject:   Re: Signals/jobs weirdness?
Message-ID:  <Pine.BSF.4.21.0208072310010.77598-100000@InterJet.elischer.org>
In-Reply-To: <20020808003942.96051.qmail@web20908.mail.yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
 EEEEKK!!!!
 patch checked in..
(it may or may not fix the problem but it sure is wrong!)


On Wed, 7 Aug 2002, David Xu wrote:

> 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?Pine.BSF.4.21.0208072310010.77598-100000>