[f]statvfs (was Re: bug in statfs)
Fri Dec 5 16:52:00 GMT 2003
Pierre Humblet wrote:
> At 03:54 PM 12/4/2003 -0500, Christopher Faylor wrote:
>>On Thu, Dec 04, 2003 at 12:52:31PM -0600, Brian Ford wrote:
>>>PS. I'm still seeing random silent "deaths" with the current cvs
>>>cygwin1.dll. Long configure scripts randomly stop in the middle.
>>>Re-running them, they might complete, or they might stop in a different
>>>spot. Even configuring/compiling Cygwin again is then a hit and miss
>>>proposition. Does anyone else see this or have an idea how to debug it?
>>I doubt that they are just silent exits.
> FWIW, on WinME I get the pop up to the effect that there was a fault in
> gdb doesn't kick in.
I hate to say "Me too", but it's been so long I can't remember when
error_start ever worked on WinME. Same error as Pierre, GPF or
something similar but no GDB ever shows up. I reported it once awhile
back, but there was little said (I assumed it was the "too bad, you use
WinME" type reaction from most people, which I've come to expect). So,
I just gave up a long time ago and resigned myself to either using
DrMingW or running stuff directly inside gdb. Of course, it would be a
good thing if someone could track this down.
As for the "silent" exit, this is something I've noticed on both Win2k
and WinME. I don't know if this is related, but for a few months now,
I've been experiencing "involuntary" logouts with bash. It happens more
often on my Win2k box when I'm logged in remotely using ssh. I'll be
running `rm -fr` or `grep -rin` on some directory tree, and then boom,
it drops me back to the client machine's command prompt. Other times,
at random, I'll login locally in rxvt via `login` and then attempt to
run `ls` as the first command, only to have myself logged out
immediately. Sometimes this event happens slow enough that I can see
the actual word "logout" before the rxvt window disappears. Also, the
interesting thing is that the history, in both cases, is preserved, so I
know bash was able to exit in a somewhat graceful manor. I suspect, but
cannot prove, that this general problem is exacerbated by
case_check:strict. I notice about a 3x increase in frequency of the
described symptoms when that setting is in effect. This goes, as well,
for the other symptom I described of multiple forked sub-processes
becoming deadlocked after a random number of forks.
I'm going to digress and address one sarcastic, rhetorical question
about why people still use or would even want to use case_check:strict.
To answer simply, gcj and (I believe) Java are unable to find
non-jar'ed class files in the CLASSPATH with any other version of that
setting. Also, some projects' cvs repos are unpullable unless this is
set (It is interesting to note that the opposite is sometimes true when
there are dirs of same name, different case and one of them is in the
Attic). Also, it makes bash command completion much more accurate.
Other times, it aides in finding the right command when binaries exist
in the PATH, but not the same dir, which share same name, but different
case (as can be seen by Harold's example). I could go on and on
evangelizing on the benefits of strict case check, but I think that my
points stated are sufficient for now. I'll close by stating a more
fundamental point which is that strict checking makes Cygwin behave in a
more POSIXly Correct manner, which can be, and often is, desirable. As
a side thought, I think it might be interesting to see how many
developers use this mode by default. As for the slowness, to borrow a
saying from Chuck, well that's like the old comedy line: "Man: Doctor,
Doctor! It hurts when I do this. Doctor: Then don't do that." Perhaps
actually optimizing and/or reworking the routine would be more fruitful
in the long term? Of course, I'm sure patches to do this will be
gratefully accepted ;-).
More information about the Cygwin-developers