www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1998/07/10/16:53:05

From: Martin Str|mberg <ams AT ludd DOT luth DOT se>
Message-Id: <199807102052.WAA04526@father.ludd.luth.se>
Subject: Re: info core dumps
To: eliz AT is DOT elta DOT co DOT il
Date: Fri, 10 Jul 1998 22:52:45 +0200 (MET DST)
Cc: djgpp-workers AT delorie DOT com (DJGPP-WORKERS)
In-Reply-To: <199807102027.WAA04323@father.ludd.luth.se> from Martin Str|mberg at "Jul 10, 98 10:27:42 pm"
MIME-Version: 1.0

According to Eli:
> On Wed, 8 Jul 1998, Martin Str|mberg wrote:
>
> > Page fault at eip=0001cb47, error=0004
> > eax=0010c000 ebx=00000006 ecx=00026125 edx=0000bf00 esi=0010c001
> edi=000000\
1b
> > ebp=000723d8 esp=0007238c program=E:\DJGPP.202\BIN\INFO.EXE
> > cs: sel=00a7  base=10000000  limit=000affff
> > ds: sel=00af  base=10000000  limit=000affff
> > es: sel=00af  base=10000000  limit=000affff
> > fs: sel=008f  base=0000ab40  limit=0000ffff
> > gs: sel=00bf  base=00000000  limit=ffffffff
> > ss: sel=00af  base=10000000  limit=000affff
> > App stack: [00072538..00032538]  Exceptn stack:
> [00032490..00030550]

[Klippa, klapp, kluppit.]

> This crash is in the library.  I attach the source of the function
> (from conio.c) where it crashes.
> 
> First, it should stop crashing if you set INFO_LINES to something
> other than 35 or 40 (40 is the default in the distributed DJGPP.ENV).
> Try 25, or 28, or 50 and see if it stops crashing.

Yes, INFO_LINES set to 35 or 40 makes info crash, while 25, 28 or 50
works fine. 

> The place where it crashes creates a 8x10 font suitable for 40-line
> display, by copying the 8x8 font from the BIOS and stretching it to
> 8x10 while it does so.  The value of EAX is the linear address of the
> BIOS font table from where it copies (ECX is the linear address of the
> destination, but the instruction which crashes doesn't access the
> destination).
> 
> Note that the value of EAX is 10C000h, which cannot be a valid
> real-mode address: it's more than 20 bits.  I cannot imagine how could
> that happen, since that address comes from function 1130h of Int 10h,
> see the code below.

Well, it does indirectly come from function 1130h of Int 10h, but note
that "src =  ( ( (unsigned)regs.x.es ) << 4 ) + regs.x.bp;" and as the
int 10h function returns es==0xffff and bp==0xbf32 (values from
running the included function; es==0xffff for info.exe as well, didn't
write down bp in that case) you'll get more than 20 bits. You'd get
more than 20 bits for bp > 0x9. That es content look suspiciously
like an error. 

> I could, of course, strip off that 21st bit, but I'd like to know
> first that this will give the right address of the font table.  I'd
> appreciate if you could step with a debugger into the function whose
> code is attached, and see what the heck is going on there.

I tried that; didn't help.

> Another thing that puzzles me is that EDI's value is 1Bh, which means
> that 27 character glyphs were already copied by the time it crashes.
> I fail to understand how could that be with such a bogus value of the
> pointer to the font table: it should have crashed while accessing the
> first character.

Yes, it crashes when i==27 and j==6.

> Btw, you seem to have a binary which is different from what I use (and
> what should be in the latest txi312b.zip): the instruction where it
> crashes for you is at 0x1cb5f in my version.  I'm sending you the
> unstripped binary together with my version of libc.a in a uuencoded
> .zip file attached below.

Strange. You can make it crash, then? The zip file I got was
corrupt. Anyway I can now (and have) compile info myself.

I hope you meant add a main function and declaring font_seg as "static
int font_seg = -1;"? That's what I did anyway. It crashes also when
i==27 and j==6.

I'll let it stay in here as I have a question about it in it.

> -----------------------------------------------------------------
> /* Stretch a 8x8 font to the 8x10 character box.  This is required to
>    use 80x40 mode on a VGA or 80x35 mode on an EGA, because the character
>    box is 10 lines high, and the ROM BIOS doesn't have an appropriate font.
>    So we create one from the 8x8 font by adding an extra blank line
>    from each side.  */
> static void
> maybe_create_8x10_font(void)
> {
>   unsigned char *p;
>   unsigned long src, dest, i, j;
> 
>   if (font_seg == -1)
>     {
>       __dpmi_regs regs;
>       int buf_pm_sel;
>       
>       /* Allocate buffer in conventional memory. */
>       font_seg = __dpmi_allocate_dos_memory(160, &buf_pm_sel);
>
>       if (font_seg == -1)
>         return;
> 
>       /* Get the pointer to the 8x8 font table.  */
>       p = (unsigned char *)malloc(2560); /* 256 chars X 8x10 pixels */

Here is some protected memory allocated. But I can't see where it is used?

>       if (p == (unsigned char *)0)
>         {
>           errno = ENOMEM;
>           __dpmi_free_dos_memory(buf_pm_sel);
>           font_seg = -1;
>           return;
>         }
>       regs.h.bh = 3;
>       regs.x.ax = 0x1130;
>       __dpmi_int(0x10, &regs);
>       src =  ( ( (unsigned)regs.x.es ) << 4 ) + regs.x.bp;
>       dest = ( (unsigned)font_seg ) << 4;
> 
>       /* Now copy the font to our table, stretching it to 8x10. */
>       _farsetsel(_dos_ds);
>       for (i = 0; i < 256; i++)
>         {
>           /* Fill first extra scan line with zeroes. */
>           _farnspokeb(dest++, 0);
> 
>           for (j = 0; j < 8; j++)
>             {
>               unsigned char val = _farnspeekb(src++);
> 
>               _farnspokeb(dest++, val);
>             }
> 
>           /* Fill last extra scan line with zeroes. */
>           _farnspokeb(dest++, 0);
>         }
>     }
> }
> 


Yes, Open Your Eyes,

							MartinS

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019