Re: /bin/sh question

[Dmitry Sivachenko]

On Sun, May 09, 2004 at 09:53:50PM -0400, Martin Cracauer wrote:
 Dmitry Sivachenko wrote on Fri, Apr 30, 2004 at 03:28:29PM +0400: 
  
  We use recent -STABLE.
  We observed /bin/sh looping forever executing a script.
  We run this script with -T option to sh(1).
  When sh(1) receives a HUP, we entering our trap handler which spawns
  child process.  When this process exits, sh(1) loops.
 
 Need a test script.  I committed a bogus change some time ago but that
 never made it into -stable, except maybe somebody else merged :-/
 
 I am not sure you are allowed to fork in a trap handler, can't check
 right now.
 

A simple test script is provided in bin/66242.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: /bin/sh question

[Martin Cracauer]

Dmitry Sivachenko wrote on Fri, Apr 30, 2004 at 03:28:29PM +0400: 
 
 We use recent -STABLE.
 We observed /bin/sh looping forever executing a script.
 We run this script with -T option to sh(1).
 When sh(1) receives a HUP, we entering our trap handler which spawns
 child process.  When this process exits, sh(1) loops.

Need a test script.  I committed a bogus change some time ago but that
never made it into -stable, except maybe somebody else merged :-/

I am not sure you are allowed to fork in a trap handler, can't check
right now.

Martin
-- 
%%%
Martin Cracauer [EMAIL PROTECTED]   http://www.cons.org/cracauer/
 No warranty.This email is probably produced by one of my cats 
 stepping on the keys. No, I don't have an infinite number of cats.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

/bin/sh question

[Dmitry Sivachenko]

Hello!

We use recent -STABLE.
We observed /bin/sh looping forever executing a script.
We run this script with -T option to sh(1).
When sh(1) receives a HUP, we entering our trap handler which spawns
child process.  When this process exits, sh(1) loops.

The backtrace is the following: 

(gdb) bt
#0  0x80763fc in wait4 ()
#1  0x8075941 in wait3 ()
#2  0x8051f8a in waitproc (block=1, status=0xbfbffa0c)
at /mnt/backup/releng_4/src/bin/sh/jobs.c:1025
#3  0x8051cbd in dowait (block=1, job=0x80c6000)
at /mnt/backup/releng_4/src/bin/sh/jobs.c:926
#4  0x8051b8a in waitforjob (jp=0x80c6000, origstatus=0xbfbffa88)
at /mnt/backup/releng_4/src/bin/sh/jobs.c:870
#5  0x804be33 in evalcommand (cmd=0x80b6d6c, flags=0, backcmd=0x0)
at /mnt/backup/releng_4/src/bin/sh/eval.c:904
#6  0x804acc0 in evaltree (n=0x80b6d6c, flags=0)
at /mnt/backup/releng_4/src/bin/sh/eval.c:281
#7  0x804aafa in evaltree (n=0x80b6e04, flags=0)
at /mnt/backup/releng_4/src/bin/sh/eval.c:199
#8  0x804aafa in evaltree (n=0x80b6e38, flags=0)
at /mnt/backup/releng_4/src/bin/sh/eval.c:199
#9  0x804aa73 in evalstring (
s=0x80c5100 rm -f /tmp/st28742.box221.zecke.demos.su; _clean SIGHUP /dev/tt
yph.28742.zecke.demos.su 28742;  exit)
at /mnt/backup/releng_4/src/bin/sh/eval.c:171
#10 0x80598da in dotrap () at /mnt/backup/releng_4/src/bin/sh/trap.c:401
#11 0x804acf6 in evaltree (n=0x80b6d00, flags=0)
at /mnt/backup/releng_4/src/bin/sh/eval.c:290
#12 0x80528f4 in cmdloop (top=1) at /mnt/backup/releng_4/src/bin/sh/main.c:250


The waitproc() at jobs.c:926 returns -1 and sets errno to ECHILD (because
the child does not exist at that time).
Since (pid = 0) condition is true at jobs.c:935, -1 is returned and we are
entering dotrap() at jobs.c:870.  dotrap() never alters (struct job *)state.

So we get an infinite loop around jobs.c:869.

Unfortunatelly I can't provide a simple enough how-to-observe script for
this, but the above logic seems weird for me.  I can provide additional
details or coredump if needed.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]