Date:	Sun, 15 Aug 1999 11:00:20 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Endlisnis <s257m AT unb DOT ca>
cc:	djgpp AT delorie DOT com
Subject:	Re: RHIDE crashes without traceback.
In-Reply-To:	<37B34DF0.55C95C69@unb.ca>
Message-ID:	<Pine.SUN.3.91.990815104524.1935B-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Thu, 12 Aug 1999, Endlisnis wrote:

>     It turns out that it has nothing to do with the DJGPP variable, but the DJDIR
> variable.  If I point DJGPP to a non-existant file, RHIDE does not crash, but it is
> not djgpp.env that is crashing rhide.exe.  I know this because if I unset DJGPP,
> and then manually set DJDIR to point to ANYTHING (valid or not), it crashes
> immediately when I run it.

It seems that it crashes somewhere in the startup code (that's the place 
where the DJDIR variable is processed by looking up and loading 
djgpp.env).  I think it would help to find out where exactly does it 
crash.  The best way to do that would be to run RHIDE under a debugger 
such as GDB or FSDB and single-step the program until it hangs.  Then 
post here the instruction where it crashed and a couple of dozens of 
instructions from its vicinity.

But first make sure the bug at all exists when you run RHIDE under a 
debugger.

Since single-stepping the startup code can be slow, as the first 
approximation I suggest to put a breakpoint at the entry to the 
__crt1_startup function, and see if you get there.  This would tell us 
better where to look for the bug.

I'd gues that you already tried to abort RHIDE with Ctrl-BREAK when it 
hangs; if you haven't, please try that now and post the traceback.

Another idea would be to run exe2coff on rhide.exe, to get the raw COFF 
image, and then try to run that COFF image through go32-v2.  If that 
works, it might mean that the stub is the culprit.  If running raw COFF 
through go32-v2 works, try running rhide.exe through go32-v2; if that 
fails, run stubify on the raw COFF image (which will; replace whatever 
stub used by Robert with the stock v2.02 one), and see if the resulting 
rhide.exe works.

> The "GPR2MAK.exe" program also crashes in the exact
> same way under all the mentioned scenarios.  But, no other program (DJGPP or not)
> is having this symptom.

Are there any other programs in the RHIDE distribution?  If there are, 
try them as well; perhaps Robert used some patched variant of the startup 
code or the library which exhibits the bug.

> Looking back, there is no way that info would help, but better to give too much
> info than not enough.

You were right in posting that info, I just wanted to make sure I didn't
miss something in your description.

- Raw text -