Date: Mon, 23 Jul 2001 14:40:16 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Andrew Cottrell <acottrel AT ihug DOT com DOT au>
cc: djgpp-workers AT delorie DOT com
Subject: Re: Make 3.791 on Windows 2000 test
In-Reply-To: <000d01c11366$ca1acaf0$0a02a8c0@acceleron>
Message-ID: <Pine.SUN.3.91.1010723143509.18357C-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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


On Mon, 23 Jul 2001, Andrew Cottrell wrote:

> > >         make.exe[1]: Entering directory `d:/dj204/gnu/make-3.791'
> > >         Extended Error 183

Any luck in finding out where did this message come from?

> > >         Call frame traceback EIPs:
> > >           0x00020818 _malloc+620
> >
> > Looks like some problem with memory corruption (that's what crashes
> > inside malloc usually mean).  Did you try to do the same with the same
> > executables on another version of Windows?  I don't recall any Make
> > crashes inside malloc.
> I used the same version of make and DJGPP on my Win98 box and it worked
> fine.

This could be due to different memory allocation startegy, and in 
particular the linear address where Windows loads our program (see the 
base address and limit values reported by the crash traceback).

> 2) Make build results (both with the same Make & Bash, both built with CVS
> LIBC & NTVDM patch):
>         WIN 98 - re-built okay
>          WIN 2K - same error
> 
> I deleted all of the files in the bin directory that I did not re-build
> yesterday, but this did not help.
> 
> Any other suggestions?

Yes, rebuild Make (on Windows 98) so that it has UNIXY_SBRK flag set in 
the __crt0_startup_flags variable.  Then try using that on Windows 2000 
to build Make, and see if that helps.

> I have download YAMD to see if this can find anything tomorrow night.

YAMD will not help you on Windows, because it relies on support for 
function 0507h of Int 31h, which is part of DPMI 1.0 and unsupported by 
Windows (this is the same function our startup code uses to uncommit the 
null page and catch NUL pointer dereferences).