Mail Archives: cygwin/2000/10/11/13:13:52
On Wed, Oct 11, 2000 at 08:34:38PM +0400, Andrej Borsenkow wrote:
>>
>>
>> On Wed, Oct 11, 2000 at 10:27:26AM +0400, Andrej Borsenkow wrote:
>> >- bash displays "logout" that it normally does when it gets EOF. So, it
>> >_looks_ like bash is getting EOF. It does not crash (well, in
>> usual sense :-)
>>
>> That is the detail that I was looking for.
>>
>> >- I've never seen this in 1.1.4 or below and bash is unchanged since
>> >then. So, it _looks_ like some change in Cygwin.
>>
>> I was not implying that this wasn't a problem in Cygwin. It obviously
>> is.
>>
>> I was asking, as usual, for *details*. I guess I forgot to ask for
>> details when I asked for people to report bugs.
>>
>
>Well, I guess, I already mentioned the "logout" message in another mail in
>this thread, may be in not so clear form.
Oops. I screwed up. I missed that. My sincere apologies.
>> How about a 'cygcheck -r -s -v'?
>>
>
>At the end
Thanks. Do you see the same problem without the CYGWIN=tty?
>> If you are motivated, an 'strace -osomefile bash', from the windows
>> command prompt demonstrating the problem would also be appreciated.
>>
>
>I am motivated. I simply cannot reproduce it running under strace, sorry. But
>here are more details, that may (or may not) be of some use.
>
>- normally, when I just start the single bash session, it exits as described
>after entering just a dozen commands (it may be more or less - but it exits
>anyway). Unfortunately, it is the only way known to me to reproduce it.
Ok. I tried that. I'll try it again.
Would you see this if you just ran, say, /bin/pwd repeatedly and kept typing
"CTRL-P, enter"?
>- it does not happen when running under strace. Under "it does not happen" I
>mean, in the time I spent trying - but it was significantly longer, than bash
>normally takes to exit.
Yeah. Strace is a great tool. It fixes almost any cygwin problem when you
run it. :-(
>- interestingly enough, it did not happen as well when I started regression
>tests for another package in another bash session (tests give CPU quite a bit
>of work). But as soon as I stopped these tests, my interactive session
>disappeared after several commands
>
>- I've never seen this running zsh
I run zsh, too. I've never seen it in bash or zsh.
When you start bash is it from a command prompt, or do you click on something?
>All of this makes me believe, that this is race condition between
>parent and child in handling of std{in,out,err}. When running on clean
>system, child simply starts "too fast". When running under load, child
>has enough time to do whatever is needed to avoid error condition. Or,
>may be, it is time that child is needed to cleanup on exit. Of course,
>it may depend on internal FD's handling in bash/zsh, that may account
>for Zsh case. Also, zsh is a bit "heavier" and does quite a bit after
>fork.
Your supposition is probably correct. I'll take a look at the
synchronization code again.
I have another supposition that cygwin is valiantly trying to display an
error message that is not showing up. I've made a few changes that will
force fatal errors to always be displayed to the console. It should be
in tonight's snapshot.
Apologies to all if I am sounding crabby about this. Getting a new
release out always puts me in a bad mood since I have to essentially say
"I think I am now invulnerable, please start shooting at me" and the
bullets sure do sting. I made my usual mistake of adding too many changes
to cygwin, this time, so tracking down what is causing the problems is
hard.
I do appreciate the tremendously the feedback that I've gotten and I
appreciate everyone's patience when I ask for excruciating details;
especially when I ask people to repeat themselves.
cgf
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
- Raw text -