delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2002/01/16/01:41:05

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 <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Charles Sandmann <sandmann AT clio DOT rice DOT edu>
cc: djgpp-workers AT delorie DOT com, Andrew Cottrell <acottrel AT ihug DOT com DOT au>
Subject: Re: ls weirdness on root drive
In-Reply-To: <10201160458.AA18094@clio.rice.edu>
Message-ID: <Pine.SUN.3.91.1020116082430.2698I-100000@is>
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

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.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019