X-Authentication-Warning:	delorie.com: mailnull set sender to djgpp-workers-bounces using -f
From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<10201161432.AA16707@clio.rice.edu>
Subject:	Re: ls weirdness on root drive
To:	eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
Date:	Wed, 16 Jan 2002 08:32:11 -0600 (CST)
Cc:	djgpp-workers AT delorie DOT com, acottrel AT ihug DOT com DOT au (Andrew Cottrell)
In-Reply-To:	<Pine.SUN.3.91.1020116082430.2698I-100000@is> from "Eli Zaretskii" at Jan 16, 2002 08:33:33 AM
X-Mailer:	ELM [version 2.5 PL2]
Mime-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> I thought fixpath converts all backslashes to forward slashes.  Does't 
> it?

Either it doesn't or lstat puts them back someplace.  At that point
in the code a debug statement showed them sometimes forward, sometimes
backward, so I just allowed both.

> > ls behavior on my home W2K system refuses to show any strangeness on
> > any drives.  So far only the C drive one one W2K system at work, and
> > only in the root directory, shows bad behavior.
> 
> I'm confused: I thought you just said you've fixed that.  Could you tell 
> what is still wrong, on that one W2K system, after you fixed the "." 
> case?

Multiple bugs.  There was the "." bug (fixed) and the missing files
from ls weirdness.  Missing files, changed behavior with ls , ls -l
still exists on some directories.

> > the env crash is scary.  At crash it's showing using around 6Mb of
> > memory with the stack at the 5.5Mb mark.  Run under the debugger
> > The stack is at 0.7Mb area.
> 
> Did you run the raw COFF image under the debugger, or the .exe file?  The 
> stack is allocated differently in these two cases, which might or might 
> not be relevant.

I was running the .exe

> > If I set the djgpp environment variable to point to a file,
> > if I make that file small it will still crash; if it is larger
> > it then runs.
> 
> This seems to point to some corruption of malloc chain, probably by some 
> code unrelated to where it crashes.  The size of the env file affects the 
> bucket where the allocated buffer goes.

Agreed; most likely explanation

> Here's an idea: link a small test program with malloc-debugging routines, 
> and try to see if the debug output tells something useful.  In particular, 
> dumping all the allocated buffers in several strategic places during the 
> startup code might be helpful.  See the docs for `mallinfo', 
> `malloc_debug', and `mallocmap' (in the CVS version of the library), for 
> more info.

I can't get it to fail in a small test program.  I can't even get the 
current binary to fail under the debugger.  (If it would, I can work
with the disassembly and source to find/fix).

But the current binary reliably fails without the debugger, or fails 
differently when run from go32-v2, or fails differently with a different
djgpp.env size.

I don't know what to say currently other than Known Bug - must set
DJGPP environment variable to point to DJGPP.ENV or malloc may be flakey.

- Raw text -