This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [f]statvfs (was Re: bug in statfs)


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?

set CYGWIN=error_start=x:\path\gdb


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
cygwin1.dll.
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 ;-).

Cheers,
Nicholas


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]