make-w32
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Problems with latest Cygwin make patch; builds OK but binary segfaul


From: William Sheehan
Subject: RE: Problems with latest Cygwin make patch; builds OK but binary segfaults
Date: Fri, 25 Aug 2006 00:57:35 -0700

> It could be an infinite recursion in 
> construct_command_argv_internal, but it could also be 
> something else.  First, is it reasonable to get a stack 
> overflow in a Cygwin program after only 11 recursive 
> invocations of construct_command_argv_internal?  Can you 
> verify directly that the stack overflowed?  If not, we need 
> to know what caused the crash.

I am not familiar with the limits of the Cygwin internals.  The reason I
suggested a stack overflow was that when I run the patched binary from
cmd.exe, I get the following output verbatim:

  28518 [main] make 2200 _cygtls::handle_exceptions: Exception:
STATUS_STACK_OVERFLOW
  30469 [main] make 2200 open_stackdumpfile: Dumping stack trace to
make.exe.stackdump

> Second, do I understand correctly that you were running "make 
> clean" in the top-level directory of make-3.81 source tree?  
> You didn't mention that explicitly anywhere (sorry if I 
> missed something), and I wouldn't want to guess.  I need to 
> know what part of the Makefile caused the crash.  If 
> possible, could you please craft a minimal Makefile that has 
> only the necessary bits to recreate the problem?

Sorry, that was a bad example that was added as a convenience.  I was under
the impression that the generated binary crashed on any Makefile, and since
I was already in a directory with a makefile, I just ran it there with the
clean target.  It turns out the Makefiles I was generating/selected were
lucky guesses, however I have narrowed down the pattern for a failed
Makefile.

The basic cause of the problems are the ~ and ! characters defined in
sh_chars, line 2304 of job.c in the untouched make 3.81 sources.  Or rather,
that a Cygwin build uses sh_chars when (I think) it should be using
sh_chars_sh.  While the patch does try to address this by adding a new
#ifdef HAVE_DOS_PATHS for sh_chars_sh around line 2309, it doesn't seem to
account for the use of sh_chars on lines 2462 and 2751.

On those two lines (2462 and 2751), I did a quick #ifdef HAVE_DOS_PATHS that
substituted sh_chars_sh instead of sh_chars, and all of the problems I had
before went away.  Whether this is a proper fix or not I am not sure; I'm
starting to grasp the logic used in the function, but not quite to zen yet
:)

My crashing problem only affects Makefiles whose actions contain the ~ or !
characters.  Here are two quick tests that should crash a patched make under
Cygwin:

$ echo 'all : ; @echo Fun!' > Makefile
$ make

$ echo 'squiggle : ; @echo creating C:/PROGRA~1/some.file' > Makefile
$ make

The latter example is very common when using 8.3 pathnames, which are still
in use with some older compilation toolchains and sometimes seen on Windows
2000 with its 2047 character command line limit.

> This is a standard feature of GNU Patch: if the patch file 
> names the file config/dospaths.m4, Patch will look in the 
> config/ subdirectory. What command did you use to invoke 
> Patch, and what version of Patch is that?

I just used the latest patch package from the Cygwin installer.  The patch
commands were in my attached .script file.  I figured it was a version
issue; thanks for the heads up. 

$ patch --version
patch 2.5.8
Copyright (C) 1988 Larry Wall
Copyright (C) 2002 Free Software Foundation, Inc.

This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of this program
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

written by Larry Wall and Paul Eggert

> Are you saying that the original unpatched binary of Make 
> 3.81 also crashes with the same Makefile?  If so, that 
> doesn't seem to say anything about the patch itself, right?

No, I was simply clarifying the output in my attached cygcheck.out file.
The cygcheck program says I have version 3.81, however in my .script file,
you will see that /usr/bin/make comes back as 3.80.  I was just describing
why that discrepency was there.

I am able to build the vanilla make 3.81 sources and everything works just
fine, final binary included.  The only difference between the two builds is
that I apply the patch(es) and run autoheader/conf before the typical
./configure && make.

William Sheehan
Builds Engineer / Network Administrator
Open Interface North America






reply via email to

[Prev in Thread] Current Thread [Next in Thread]