X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f Date: Wed, 16 Jan 2002 08:33:33 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Charles Sandmann cc: djgpp-workers AT delorie DOT com, Andrew Cottrell Subject: Re: ls weirdness on root drive In-Reply-To: <10201160458.AA18094@clio.rice.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk On Tue, 15 Jan 2002, Charles Sandmann wrote: > > "." shows an error with lfn active under 2.04 but no error under 2.03, > > and no error on the same exe with lfn=n on 2.04. > > Fixed this one (lstat.c). I introduced it when doing relative > paths - didn't know the the fixpath'ed string could have both > forward and backward slashes. I thought fixpath converts all backslashes to forward slashes. Does't it? > 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? > 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. > 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. 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.