On Fri, Feb 11, 2011 at 8:57 AM, Illia Bobyr
<illia.bo...@ronin-capital.com> wrote:
> On 2/9/2011 3:57 PM, Linus Torvalds wrote:
>>
>> Here's the scenario:
I'll quote the scenario again, because you clearly didn't bother to read it.
Please _READ_ it this time before you answer, ok?
>> - wait_for() sets wait_sigint_received to zero (look for the comment
>> here!), and installs the sigint handler
>> - it does other things too, but it does waitchld() that does the
>> actual waitpid() system call
>> - now, imagine the following scenario: the ^C happens just as the
>> child already exited successfully!
>> - so bash itself gets the sigint, and sets wait_sigint_received to 1
Let me repeat: THE CHILD ALREADY EXITED SUCCESSFULLY. IT NEVER SAW THE ^C.
So 'bash' saw the ^C that came from the keyboard. And the exit status
from the child does NOT show SIGINT, because the child never saw it.
> Do we really need to check wait_sigint_received here?
Jesus wept. YES.
Because the ONLY thing that has seen the SIGINT is bash. If bash then
ignores "wait_sigint_received", then bash has lost the ^C.
> If the child exits because of SIGINT was indeed received [..]
The amount of pure denial in this thread is astounding.
The bug has been analyzed. I told you exactly what happened. Please
don't make up some unrelated and totally pointless scenarios.
The child exited BECAUSE THE CHILD EXITED. The example child is
"/bin/true", for chissake. It exits immediately. It never saw the ^C.
The "waitpid()" will return a successful exit, so WTERMSIG() will be
zero.
If bash ignores 'wait_sigint_received' in this case, then ^C has been
lost. Which is the bug.
> Maybe the patch should be
No.
> I'm not an expert on Unix signals, but it seems that it is possible to
> tell. Via WTERMSIG (child->status).
Christ, NO!
You didn't read the bug report. Go back and read it. It has a full analysis.
The point is, and let me repeat this for the FIFTH time, since
apparently it's not really being appreciated: the child exited before
the ^C happened. There is no WTERMSIG().
> Again according to the "Proper handling of SIGINT/SIGQUIT" (*) the
> child is supposed to "rekill" itself if it wishes to do any cleanup
.. and this is just empty blathering, because you didn't read, and
didn't understand, the problem.
The child was never killed to begin with. t wasn't even RUNNING when
the ^C happened. The only thing running was 'bash'.
And bash ignores it, exactly because bash has the buggy
if (wait_sigint_received&& (WTERMSIG (child->status) == SIGINT) && ..
test. The WTERMSIG() part of the test is broken.
It's really simple: wait_sigint_received means that bash got a SIGINT.
And ff bash got a SIGINT, then the user pressed ^C. Any random value
of WTERMSIG() and the fact that the child didn't see it is TOTALLY AND
UTTERLY IMMATERIAL.
So ignoring ^C just because it didn't happen while the child was
running is wrong. And telling people that you should check the exit
status of the child is WRONG.
Can we please stop with the stupidity already? Can we please stop with
the "I can't reproduce this" excuses? Can we please stop this "I'm
running OS X and I don't see it" crap? Can we please stop with the "I
didn't even read the bug report, but I'm going to make excuses
anyway"? Can we please stop with the denial?
It's a bug in bash. It really is that simple. Stop making excuses.
Read the source code, and read the bug report.
Linus
