From: pavenis AT lanet DOT lv
To: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>, djgpp-workers AT delorie DOT com
Date: Fri, 26 May 2000 20:18:53 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: gcc djgpp stopped working
Message-ID: <392EDC2D.15119.171CE80@localhost>
In-reply-to: <200005261637.TAA01181@mailgw1.netvision.net.il>
References: <392EBD54 DOT 13380 DOT F946F1 AT localhost> (pavenis AT lanet DOT lv)
X-mailer: Pegasus Mail for Win32 (v3.12c)
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 26 May 2000, at 19:36, Eli Zaretskii wrote:

> > From: pavenis AT lanet DOT lv
> > Date: Fri, 26 May 2000 18:07:16 +0200
> >
> > > > From: "Dr. J. Robert Lee" <jrl AT netcom DOT com>
> > > > Date: Fri, 19 May 2000 08:13:18 -0700
> > > > 
> > > > Thanks very much for pointing me in the right direction. The directory
> > > > pointed to by TMPDIR had been magically changed into a file. I removed
> > > > the file and re-created the directory. Now gcc works just fine.
> > > 
> > > I would suggest that the function that creates a temporary file return
> > > some error indication, and GCC then would print a self-explanatory
> > > error message, instead of aborting.  That would probably allow many
> > > users to find the problem by themselves, instead of asking the gurus...
> > 
> > Tried to play with related things (breaking environment, renaming 
> > c:/tmp, creating  plain file with such name etc) but failed to break gcc 
> > and other stuff (no crashes or other weird things). For example gcc still 
> > used root directory for placing temporary files. 
> 
> I don't know what are the exact circumstances where this problem
> happens (I suspect that it involves a corrupt FAT or a FAT that was
> corrupted and repaired by SCANDISK).  However, I do see 2 calls to
> abort() in the function choose_temp_base; evidently one of them was
> causing the crash.  What I suggested was that this function will print
> a self-explanatory error message instead.
> 
> In general, a program should not abort if the problem could be solved
> by user-level means (such as changing an environment variable),
> renaming or deleting files, etc.  Aborting and dumping core should be
> reserved for situations where the user cannot possibly help, like some
> crazy inconsistency in internal data structures.

Looked sources in gcc2952s.zip (latest update not ones uploaded to 
ftp.delorie.com, but I haven't changed any related thing for along time)

There is possibility of some problems:

Let assume gcc tries to create file in TMPDIR=c:/tmp and directory 
with the same name already exist there. Then it gets EPERM (If there is 
busy file I got EEXIST at least in DOS session under Win98 SE). That 
is rather unlikely as biostime() is used to generate first file name (and 
it's later incremented). In this case (BUG) it's assumed that directory is 
bad and it quits the loop. Function mkstemp() in libc also has this 
problem (if it gets EPERM it quits the loop)

Perhaps mkstemp should use stat() if it gets EPERM to verify whether
file (or directory) exists and and only give up if it's doen't exist.

Anyway I think that running into this problem is very unlikely

Andris