Date: Tue, 22 Apr 1997 22:36:08 +1000 From: Bruce Evans <bde@zeta.org.au> To: ache@nagual.ru, current@FreeBSD.ORG, dyson@FreeBSD.ORG Subject: Re: Recent vfork kernel changes broke csh & tcsh! Message-ID: <199704221236.WAA18843@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> Both csh and tcsh affected in the similar way.
>
>I forgot to mention that I am shure it is vfork problem because it
>disappearse when I change vfork to fork in csh or tcsh.
It wasn't completely clear that you have to start from csh or tcsh
to see the bug.
It may be a csh bug. csh does a lot of work to preserve the parent
state. It's not clear that this can work with an optimising compiler.
However, compiling without -O and declaring all local variables as
volatile didn't help.
It's silly that csh ttempts to optimize forks but sh doesn't.
I think I found other bugs while attempting to debug this:
UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND
15 7403 1 0 -18 0 440 0 thrd_s DE v3- 0:00.00 (csh)
^ unkillable disk wait
(parent was gdb)
15 7742 7403 2 28 0 0 0 - Z v3- 0:00.00 (sh)
15 8334 1 0 -18 0 440 0 thrd_s DE v3- 0:00.00 (csh)
^ easy to reproduce
15 8336 8334 3 28 0 0 0 - Z v3- 0:00.00 (sh)
15 8846 1 1 -6 0 0 0 - Z v3- 0:00.00 (bash)
^ exiting login shell hung
15 8916 1 0 -18 0 440 0 thrd_s DE v3- 0:00.00 (csh)
15 8917 8916 4 29 0 0 0 - Z v3- 0:00.00 (sh)
15 8918 1 0 10 0 248 484 wait S v3- 0:00.13 /bin/sh /tmp
To reproduce this using a statically linked csh:
1) gdb csh
2) put a breakpoint at the first statement in the parent.
3) r
4) /tmp/a.sh
5) s [repeat this until the first function call (xfree). Then there is
an unexpected EFAULT and csh in state DE]
More fiddling with this gave a completely revoked ttyv3 with no getty on
it since the login shell didn't exit properly.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704221236.WAA18843>