Mail Archives: djgpp/1999/10/28/17:42:52
> Forsberg Sakari writes:
> > Call frame traceback EIPs:
> > 0x0002ba7b _gettextinfo+567
> > 0x0002baaf _gettextinfo+619
> > 0x0002bb3b _gettextinfo+759
> > 0x0002bc70 __set_screen_lines+300
> > 0x00027d32 _term_init+82. line 259 of iodjgpp.c
> > 0x0000e652 _main+1250, line 396 of fed.c
> > 0x0002a36a ___crt1_startup+174
>
> That's very strange, and starts to look like it might be a libc
> problem
It's always a possibility, but I don't think it's a library bug. One
possible problem with calling _set_screen_lines is that it crashes
under some versions of EMM386 (see section 6.10 of the FAQ). When
this problem was reported, debugging it showed that it's a blatant bug
in EMM386: it generated a page fault for an address inside the
conventional memory! (_set_screen_lines accesses the address of a
system font, because it creates a streched font to be used in the
40-line text mode.) Usually, this bug is triggered when CONFIG.SYS
loads DISPLAY.SYS, and the offending address is in the UMBs, probably
because DISPLAY.SYS loads its own font instead of the default one in
the BIOS.
That's why I asked about CONFIG.SYS and the screen dimensions used by
FED: this problem only happens in 40-line mode.
> The strangest thing of all is that looking in conio.c, the
> _set_screen_lines() function doesn't even call gettextinfo()!
> It does call _gettextinfo(), but that's not what shows up in
> the traceback (remember that you have to strip a leading
> underscore to go from symify names to C source names).
This is ``normal'': when functions are inlined by the compiler, and
sometimes even without inlining, the traceback shows incorrect
function name for static functions. If you disassemble at those
addresses, you will see that these offsets are not inside gettextinfo,
they are inside other functions declared static inside conio.c.
> > Remember that it works fine under windows...
>
> This normally means some NULL pointer access is going on, but
> I don't obviously see where this would be in the sources.
To see whether this is the same problem, you need to disassemble at
the point of the crash and see what parts of the source are involved,
and whether it dies in the loop that copies the system font into an
allocated buffer. It seems likely that this is the problem, since the
registers' dump is replete with values like eax=0010f212, which point
to the UMB--exactly where the bug documented in FAQ 6.10 happened.
- Raw text -