Date:	Sun, 22 Jul 2001 14:26:18 +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:	<001901c11296$8b501440$0a02a8c0@acceleron>
Message-ID:	<Pine.SUN.3.91.1010722141132.6415L@is>
MIME-Version:	1.0
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

On Sun, 22 Jul 2001, Andrew Cottrell wrote:

> 1) Does this look like the same problem as before the NTVDM patch?

No.  The message "Load error: can't switch mode" means that the PM entry 
point called by the startup code (to switch to protected mode) fails.  
This is known to happen after many nested DPMI programs were run in the 
same DOS box, and the usual procedure is either restart Make or close and 
open the DOS box.

If restarting doesn't help (you seem to tell it did), we have a new 
problem on our hands ;-)

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

This error message comes from somewhere outside Make and DJGPP in 
general.  It probably comes from cmd.exe or some such.  It is important 
to understand what exactly causes it.

Was the version of make.exe that you run here built with the NTVDM patch 
or not?  Was it built with CVS or stock v2.03 libc?

>         Putting child 0x000ea834 (all-recursive) PID 123 on the chain.
>         Live child 0x000ea834 (all-recursive) PID 123
>         Reaping winning child 0x000ea834 PID 123
>         Exiting due to signal SIGSEGV
>         General Protection Fault at eip=00020818
>         eax=ffa90000 ebx=ffa90000 ecx=000001d7 edx=ffaa0000 esi=ffa94010 edi=00004000
>         ebp=000bf684 esp=000bf65c program=d:\dj204\bin\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=0000a5e0  limit=0000ffff
>         gs: sel=020f  base=00000000  limit=0010ffff
>         ss: sel=01ff  base=01d70000  limit=7e27ffff
>         App stack: [000c480c..0004480c]  Exceptn stack: [00044218..000422d8]
> 
>         Call frame traceback EIPs:
>           0x00020818 _malloc+620
>           0x000334fc __flsbuf+92
>           0x00022111 _fputs+257
>           0x00025c5f __shell_command+1179
>           0x00026a91 _system+649

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.

> 2) Added a line in job.c before the system call to display the cmdline and
> then re-ran make and
> the following was the cmdline:
>     CMDLINE start = 'echo Making all in glob'
> 3) Added a line after the system call to display the return code from teh
> system call, but this was not displayed.

Yes, the above traceback clearly shows that the crash happened inside one 
of the subroutines of the `system' library function.

> Packages not re-built, but they are installed.
> amake-1.4       autocnf2.13     bash-2.03       bash-2.04       bash-2.05

I'd suggest to rebuild at least Bash (the version you use normally), 
because building other packages frequently involves Bash called from 
Make, or running configure scripts.

- Raw text -