Mail Archives: djgpp/1999/07/26/02:41:51
On Sun, 25 Jul 1999, Cesar S. Rabak wrote:
> >> Exiting due to signal SIGINT
> >> Control-Break Pressed at eip=00010ce6
> >> eax=00000000 ebx=00000021 ecx=00000000 edx=0000000e esi=00000054
> >> edi=000643ac
> >> ebp=0006439c esp=00064390 program=D:\DEVELOP\TEST\DBGINFO\TESTIT
> >> cs: sel=00ef base=83231000 limit=0007ffff
> >> ds: sel=00f7 base=83231000 limit=0007ffff
> >> es: sel=00ff base=83231000 limit=0007ffff
> >> fs: sel=0117 base=00015bf0 limit=000028ff
> >> gs: sel=0107 base=00000000 limit=ffffffff
> >> ss: sel=00f7 base=83231000 limit=0007ffff
> >>
> >> Call frame traceback EIPs:
> >> 0x00010ce6 ___dpmi_int+114
> >> 0x0000da99 _getch+49
> >> 0x00001de1 _main+29
> >> 0x0000d0aa ___crt1_startup+138
> >
> >This seems to indicate that there's a real problem with line-number
> >info in this program: symify didn't print them as well. Could you
> >please make this binary available for downloading, or send it to me?
> >I want to look into it some more.
> >
> >This traceback also shows that you still use v2.01 library. Why?
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Will you pardon, but _how_ do we figure this in the traceback?
There are two telltale signs:
- The limit of the segment whose selector is loaded into GS is -1.
Since we are inside __dpmi_int, GS likely holds the _dos_ds
selector (library functions that communicate with DOS/BIOS call a
special variant of _farptr functions which use the GS register
instead of FS). _dos_ds had a limit of -1 in v2.01, whereas v2.02
resets it back to 1MB+64KB.
- The stack dump in v2.02 and later includes an additional line with
stack limits, right below the registers' dump, like this:
App stack: [00391054..00311054] Exceptn stack: [0018b0e0..001891a0]
- Raw text -