Date: Sun, 15 Aug 1999 11:00:20 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Endlisnis cc: djgpp AT delorie DOT com Subject: Re: RHIDE crashes without traceback. In-Reply-To: <37B34DF0.55C95C69@unb.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk 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.