From: Eli Zaretskii Newsgroups: comp.os.msdos.djgpp Subject: Re: Does FED has a bug? Date: Thu, 28 Oct 1999 19:11:51 +0200 Organization: NetVision Israel Lines: 52 Message-ID: References: <7v9108$n77$1 AT baker DOT cc DOT tut DOT fi> NNTP-Posting-Host: is.elta.co.il Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: news.netvision.net.il 941130631 7409 199.203.121.2 (28 Oct 1999 17:10:31 GMT) X-Complaints-To: abuse AT netvision DOT net DOT il NNTP-Posting-Date: 28 Oct 1999 17:10:31 GMT X-Sender: eliz AT is In-Reply-To: <7v9108$n77$1@baker.cc.tut.fi> To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > 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.