Mail Archives: djgpp/1999/08/18/16:50:44
On Sun, 15 Aug 1999, Endlisnis wrote:
> 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.
This sounds like a network timeout delay. I agree with Salvador: some
environment variable probably points to a non-existent drive, or its name
looks like a UNC (a.k.a. network share) name.
> There's no debug info in the executable...so the function names wouldn't be there??
Yes. You will need to know the address of __crt1_startup, which isn't
easy. However, since you managed to produce a few tracebacks, you now
know the address of __crt1_startup: it's the last address printed, see
below.
> 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]
There's nothing special about this traceback, except that it indicates
that RHIDE is inside a __dpmi_int call (ES and SS are not equal to DS,
because __dpmi_int points them to the DS alias selector, for some obscure
reasons).
If somebody has the sources from which this binary was produced (I
don't), they could see where exactly do the first few addresses point.
> 0x000f46c6
This is the address of the entry into __crt1_startup.
- Raw text -