Date:	Mon, 26 Feb 2001 08:42:11 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Michael Allison <michael DOT allison2 AT sympatico DOT ca>
cc:	djgpp AT delorie DOT com
Subject:	Re: Eradicating djgpp W2000 problem
In-Reply-To:	<wkbm6.226404$Pm2.3670275@news20.bellglobal.com>
Message-ID:	<Pine.SUN.3.91.1010226084152.21073B@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Sun, 25 Feb 2001, Michael Allison wrote:

> Debugging it using GNU Make is too daunting, so if we build a
> set of minimal C problems to force it to happen, we might get
> someplace.

IMHO, a bad idea.  We've been there and done that already: if you go
this way, you will waste lots of time and effort just looking for a
way to reproduce the problem reliably.  Past experience suggests that
there's some randomality involved in these crashes, so you might be
mistaken to think the problem disappeared in some situation when in
fact it's just low probability.

Why not learn from past experience and pick up where this issue was
left off?  We _know_ that running programs from Make crashes NTVDM
quite reliably, so I suggest to start there.

And there's nothing daunting in debugging Make.  There's a single
source file (job.c) involved in launching programs, and only a few
library functions (`spawnve', `system', and the exception-related code
in dpmiexcp.c) from the library side.  There are people on this group
who know the library innards aas well as their way inside Make.  So we
don't have any reasons to be scared by Make.  Make is a relatively
simple program, believe me.

So I suggest to start with Make which calls another instance of Make
which calls either Make or some simple test program.

- Raw text -