Mail Archives: djgpp/1999/08/16/21:58:20
Eli Zaretskii wrote:
> 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.
OK, I've discovered that it doesn't actually "crash", it just get's hung for ~2
minutes when trying to do something with DJDIR. Running it in gdb doesn't change
anything. Using exe2coff/go32-v2 doesn't change anything. If I wait 2 minutes, it loads
and runs normally. During the 2 minute wait, it does not respond to ^C/^Break.
(Remember, it still loads normally under DOS)
> 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.
There's no debug info in the executable...so the function names wouldn't be there??
> 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.
But, I have been able to get a partial trace-back by pressing ^Break/^C about 100 times.
Here it is:
cs: sel=00a7 base=84567000 limit=^C
001dffff
ds: sel=00af base=84567000 limit=001dffff
es: ^C
: sel=00b7 base=84567000 limit=001dffff
fs: sel=00bf ba^C
base=00000000 limit=0010ffff
gs: sel=00bf base=0000000^C
00000000 limit=0010ffff
ss: sel=00b7 base=84567000 limi^C
limit=001dffff
App stack: [001be068..0017e068] Exceptn ^C
] Exceptn stack: [0017da44..0017bb04]
Call frame traceb^C
Call frame traceback EIPs:
0x000f6fa6
0x00107647
0^C
0x000f4f28
0x0010ca7c
0x0010cf31
0x0002d35b
^C
0x0002c87d
0x0002c8cf
0x0002c9ac
0x0002cc32
^C
0x0002c87d
0x0002c8cf
0x0002c9ac
0x0002d3df
0x0002c87d
0x0002c8cf
0x0002c9ac
0x0002ca6b
0x0001de74
0x0001f21a
0x0001f239
0x00020c0c
0x00010e42
0x000111f1
0x000f46c6
Also, now it seems that pressing ^C more than 100 times makes it go back to DOS
without a traceback (without ANY output).
> > 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.
"rhgdb.exe" comes with RHIDE, but seems to work normally.
I managed to get another different traceback...
Control-Break Pressed at eip=000f6fa6
eax=00000000 ebx=00000021 ecx=00000000 edx=0000cf1d esi=001d8b3d edi=001bd318
ebp=001bd308 esp=001bd2f8 program=E:\DJGPP\BIN\RHIDE.EXE
cs: sel=00a7 base=845a5000 limit=001dffff
ds: sel=00af base=845a5000 limit=001dffff
es: sel=00b7 base=845a5000 limit=001dffff
fs: sel=00bf base=00000000 limit=0010ffff
gs: sel=00bf base=00000000 limit=0010ffff
ss: sel=00b7 base=845a5000 limit=001dffff
App stack: [001be068..0017e068] Exceptn stack: [0017da44..0017bb04]
Call frame traceback EIPs:
0x000f6fa6
0x00107647
0x000f4f28
0x0010ca7c
0x0010cf31
0x0002d35b
0x0002c87d
0x0002c8cf
0x0002c9ac
0x0002cc32
0x0002c87d
And one more full traceback:
Exiting due to signal SIGINT
Control-Break Pressed at eip=000f6fa6
eax=00000000 ebx=00000021 ecx=00000000 edx=0000cf1d esi=001d9add edi=001bd318
ebp=001bd308 esp=001bd2f8 program=E:\DJGPP\BIN\RHIDE.EXE
cs: sel=00a7 base=845a5000 limit=001dffff
ds: sel=00af base=845a5000 limit=001dffff
es: sel=00b7 base=845a5000 limit=001dffff
fs: sel=00bf base=00000000 limit=0010ffff
gs: sel=00bf base=00000000 limit=0010ffff
ss: sel=00b7 base=845a5000 limit=001dffff
App stack: [001be068..0017e068] Exceptn stack: [0017da44..0017bb04]
Call frame traceback EIPs:
0x000f6fa6
0x00107647
0x000f4f28
0x0010ca7c
0x0010cf31
0x0002d35b
0x0002c87d
0x0002c8cf
0x0002c9ac
0x0002cc32
0x0002c87d
0x0002c8cf
0x0002c9ac
0x0002cccb
0x0002c87d
0x0002c8cf
0x0002c9ac
0x0002ca6b
0x0001de74
0x0001f21a
0x0001f239
0x000095f4
0x00010cd2
0x000111cb
0x000f46c6
--
(\/) Endlisnis (\/)
s257m AT unb DOT ca
Endlisnis AT HotMail DOT com
ICQ: 32959047
- Raw text -