www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1996/07/11/11:20:45

Date: Thu, 11 Jul 1996 18:11:34 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Oberhumer Markus <k3040e4 AT c210 DOT edvz DOT uni-linz DOT ac DOT at>
Cc: djgpp-workers <djgpp-workers AT delorie DOT com>
Subject: Re: gdb crashes if environment too big
In-Reply-To: <199607111355.PAA21159@c210.edvz.uni-linz.ac.at>
Message-Id: <Pine.SUN.3.91.960711180547.7736E-100000@is>
Mime-Version: 1.0

On Thu, 11 Jul 1996, Oberhumer Markus wrote:

> Recently I've changed my environment (about 6000 from 8192 bytes used),
> and now I'm encountering a bug when starting gdb or fsdb.
[snip]
> Call frame traceback EIPs:
>   0x00018c85   ___dj_movedata+33
>   0x00011696   _v2loadimage+1106, line 145 of v2load.c

Seems like a bug in v2load.c to me.  If you debug an unstabbed COFF 
image, it assumes (on line 91) that stubinfo.minkeep is 4KB (a left-over 
from v1.x?), allocates DOS memory for that many bytes, then boldly goes 
on to move the environment block into that DOS buffer.

If the above analysis is correct, you should not see such problems when 
you debug a stubbed .exe program (gdb cannot do this currently, but other 
debuggers can).  Can you see if running fsdb on a stubbed executable 
avoids such problems?

- Raw text -


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