From: rupp AT gnat DOT com (Douglas B. Rupp)
Message-Id: <9702030240.AA23793@nile.gnat.com>
Subject: Re: bash and make gnat1 (or cc1plus)
To: djgpp-workers AT delorie DOT com
Date: Sun, 2 Feb 1997 21:40:56 -0500 (EST)
In-Reply-To: <9702022100.AA22077@nile.gnat.com> from "Douglas B. Rupp" at Feb 2, 97 04:00:19 pm
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2357      

> 
> After spending some time trying to debug this I discovered that make 
> builds a command line that looks like:
> 
> /bin/sh.exe -c cd ada;  D:/DJGPP/BIN/make.exe "AR_FLAGS=rc" 
> "AR_FOR_TARGET=/usr/local/i386-go32-msdos/bin/ar" "BISON=bison" "BISONFLAGS=" 
> "CC=`case 'gcc' in stage*) echo 'gcc' | sed -e 's|stage|../stage|g';; *) 
>    echo 'gcc';; esac`" 
> "CFLAGS=-g" "GCC_FOR_TARGET=./xgcc -B./" "LDFLAGS=" "LEX=flex" "LEXFLAGS=" 
> "MAKEINFO=makeinfo" "MAKEINFOFLAGS=" 
> "RANLIB_FOR_TARGET=/usr/local/i386-go32-msdos/bin/ranlib" 
> "RANLIB_TEST_FOR_TARGET=[ -f /usr/local/i386-go32-msdos/bin/ranlib ]" 
> "SHELL=/bin/sh.exe" "exeext=" "objext=.o" "exec_prefix=/usr/local" 
> "prefix=/usr/local" "tooldir=/usr/local/i386-go32-msdos" 
> "bindir=/usr/local/bin" "libsubdir=/usr/local/lib/gcc-lib/i386-go32-msdos/2.7.2"
> "ADA_FOR_BUILD=" "ADAFLAGS=-gnatpg -gnata" "ADA_FOR_TARGET=" 
> "INSTALL_DATA=install -c" ../gnat1
> 
> and calls system() after removing the "/bin/sh.exe -c".
> 
> system() then creates a temp file e.g d:/djgpp/tmp/dj100000, and writes the 
> command to it.  System() then calls 
> _dos_exec ("/bin/sh.exe", "d:/djgpp/tmp/dj100000", environment);
> 
> and then a sigsegv occurs in _dos_exec().  The interesting thing is that I
> can arrange to save the temp file and execute a test program that
> simply calls system ("/bin/sh.exe d:/djgpp/tmp/dj100000"), and it works
> fine. But if I hack make to hardcode in this identical call (in job.c), it
> blows up with the same sigsegv.
> 
> One other thing, symify of the traceback from make gives complete garbage.
> Also running make under gdb results in a completely bogus traceback.
> 
> Anybody have any ideas?
> 

After spending more time trying to debug this, reading the FAQ, Knowledge
Base, etc.  I discovered:

1) Increasing the stack size and/or transfer buffer has no effect.
2) Increasing the size of the cwsdpmi internal heap has no effect.

The sigsegv (a general protection fault) occurs at line 325 of dosexec.c
on a call to __dpmi_int (0x21, &r), w/ r.x.ax = 0x4b00.

THe problem goes away if this line is removed from the command:
> "CC=`case 'gcc' in stage*) echo 'gcc' | sed -e 's|stage|../stage|g';; *) 
>    echo 'gcc';; esac`" 

My guess is that the expansion of this inline expression in a call to
system()/dosexec() is overflowing some internal buffer.