From: Martin Str|mberg 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 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk 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, ®s); > 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