From: k3040e4 AT c210 DOT edvz DOT uni-linz DOT ac DOT at (Oberhumer Markus)
Message-Id: <199607141656.SAA27063@c210.edvz.uni-linz.ac.at>
Subject: Re: gdb crashes if environment too big
To: djgpp-workers AT delorie DOT com (djgpp-workers)
Date: Sun, 14 Jul 1996 18:56:31 -0200 (MET DST)
Return-Read-To: markus DOT oberhumer AT jk DOT uni-linz DOT ac DOT at
Content-Type: text


===============================================================================
Markus F.X.J. Oberhumer <markus DOT oberhumer AT jk DOT uni-linz DOT ac DOT at>

Subject: Re: gdb crashes if environment too big
To: djgpp-workers AT delorie DOT com
===============================================================================

Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote:

> 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?

Yes, you are right. It works fine with stubbed executables.
The size of the environment is computed anyway, so the
bug in v2load.c should be easy to fix.

BTW, did your recent patch for dosexec.c include a test for
a possible environment overflow ? Looks like we should add a 
test for talloc().