Date: Sat, 28 Jul 2001 10:10:26 +0300
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: acottrel AT ihug DOT com DOT au
Message-Id: <2110-Sat28Jul2001101026+0300-eliz@is.elta.co.il>
X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9
CC: djgpp-workers AT delorie DOT com
In-reply-to: <009801c11716$fa32b0f0$0a02a8c0@acceleron> (acottrel@ihug.com.au)
Subject: Re: Make 3.791 on Windows 2000 test
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1010725114406 DOT 14848D-100000 AT is> <009801c11716$fa32b0f0$0a02a8c0 AT acceleron>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> From: "Andrew Cottrell" <acottrel AT ihug DOT com DOT au>
> Date: Sat, 28 Jul 2001 13:35:41 +1000
> 
> > > One possibility would be to turn on malloc debugging in Make (see
> > > "info libc alpha malloc_debug" in the CVS version of the library), and
> > > set the debug level to the highest possible value.  If this is a
> > > genuine memory allocation bug, the malloc debugging code might catch
> > > it.
> 
> Interesting as the problem changed when I added the malloc_debug(x)
> function call in make.c.

That's expected for subtle problems like this one...

> The exe with the malloc_debug(x) took considerably
> longer to start to do anything and as the value moved from 1 to 4 the longer
> it took.

Also expected: the consistency checks made by malloc, and the
information it records for each allocation and deallocation take lots
of cycles, because the data structures it uses are criminally simple
and stupid.

> Exiting due to signal SIGSEGV
> General Protection Fault at eip=00020858
> eax=ffa90000 ebx=ffa90000 ecx=000001d7 edx=ffaa0000 esi=ffa94010
> edi=00004000
> ebp=000c052c esp=000c0504 program=d:\dj204\gnu\make-3.791\make.exe
> cs: sel=01f7  base=01d70000  limit=7e27ffff
> ds: sel=01ff  base=01d70000  limit=7e27ffff
> es: sel=01ff  base=01d70000  limit=7e27ffff
> fs: sel=01cf  base=0000a4c0  limit=0000ffff
> gs: sel=020f  base=00000000  limit=0010ffff
> ss: sel=01ff  base=01d70000  limit=7e27ffff
> App stack: [000c56b4..000456b4]  Exceptn stack: [000450c0..00043180]
> 
> Call frame traceback EIPs:
>   0x00020858 _malloc+620

Looks like malloc_debug doesn't help here.

Charles, assuming that this is indeed some address-wrapping problem,
could you suggest some testing and/or changes in crt0.S to try to
identify the problem or fix it?  Perhaps some signed/unsigned problems
disrupt the logic there when the address wraps around?