Re: Bug in builtin wait when there are no kids?

Re: Bug in builtin wait when there are no kids?

[Byron Rakitzis]

Re: the bug rich found. This had nothing to do with the wait system call
and has since been fixed.

Re: ignoring your mail. I don't think it's fair to say that; I have
tried to pay close attention to every piece of mail I've received, at
least to say "ok, I've read this, I'll digest at it later", but there
is just no way that I can get around to doing everything on everybodies
wish list and still have time to breathe. I trust people can appreciate
this.

Re: broken wait. There are, as you point out, two sides to the
argument.  One the one hand, an interrupt in any routine which
performs allocation could hose rc, and it is true that I made the
tacit assumption that interrupts are just not part of the game.
On the other hand, rc is "broken", as seen by the opposing view.

In my defense, I can only offer the following couple of thoughts: 1) I
never use signal handlers myself, and I would never use them for more
than clean up & exit type work. 2) I do not consider myself knowlegable
enough to deal with the problem right now. I don't know how signal()
is implemented say, in System V, and nor do I feel particularly inclined
to try to find out in order to fix signal handlers in rc. Frankly, there
are more important things for me to do with my life. 3) However, if someone
feels the urge to work on this problem, and has a real handle on it, then
I will do my best to act as a maintainer of rc's source.

I'm sorry if this attitude is disappointing to anyone, but after nearly
a year of work on rc, I feel it is time to shunt it off to one side. Unless
someone can show me a real reason (not the fake example cited above) why
signal handlers in rc need to be fixed, then I'm not going to get particularly
excited about this bug in rc.

Re: Bug in builtin wait when there are no kids?

[John Mackin]

Rich has come across one of the many ways to break rc's waiting.  I
wasn't going to talk about this on the list, since I believe that
it's not really the done thing, but as I have explained to Byron
how this needs to be fixed and he has ignored me, I've decided I
need to speak out.

The way rc waits now is totally bogus.  All it takes is an interrupt
at the wrong time and the data structures go to hell.  Another easy way
to provoke it is this (last tried in 1.1gamma):

; fn sigiot { /bin/echo pus; /bin/echo pus }
; kill -6 $pid

Infinite loop.

This really -must- be fixed.  Ignoring this issue isn't an acceptable
solution; neither is adopting the position that since there is no
mutual exclusion in, for example, malloc, the game is over anyway.
In a theoretical sense that is true, but the fact of the matter is
that rc is most likely to receive a signal during wait(), so it is
well worth the effort to use proper data structures that cannot
become corrupted under these conditions.

I do not claim that it is good to have to do this.  I believe that
the way the wait() system call works is quite bad, and presents
difficult problems for shell authors.  I do believe, notwithstanding
that, that it must be done.  Byron, I would appreciate a statement
as to your position on this matter; I know you don't want to do anything
to rc now beyond bug fixes, but I can't believe that you don't agree
that this is a bug.

OK,
John.

Re: Bug in builtin wait when there are no kids?

[Byron Rakitzis]

ouch. This is not what it appears to be, i.e., there are no
core dumps involved. still, it's a nasty bug. All that's happening
is that $status is getting set with an uninitialized variable.
Oops.

Bug in builtin wait when there are no kids?

[Rich Salz]

; whatis prompt   
prompt=('; ' ' ;; ')
fn prompt {{LastStatus=$status;~ $LastStatus 0||echo '[Exit '^$LastStatus^']'}}

With no sub-processes running:
; wait
segmentation violation
[Exit sigsegv]
; wait
segmentation violation
[Exit sigsegv]