Re: Two snapshot bugs

[Chris Faylor <cgf at cygnus dot com>]

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@sourceware.cygnus.com