Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Date: 12 Sep 2001 13:39:45 -0400
Message-ID: <20010912173945.25925.qmail@lizard.curl.com>
From: Jonathan Kamens <jik AT curl DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: Useful details about the Make SEGVs

I recompiled my Make with debugging symbols and got it to SEGV again,
and it did, indeed, provide MUCH more useful information than before.
Here's the stack trace of the main thread in the crashed make.exe:

  #0  0x410792 in exec_command (argv=0x7, envp=0xa01eff8)
      at /u/jik/systems-cvs-root/cygwin/make/job.c:2317
  #1  0x61085842 in read (fd=7, buf=0xa01eff8, cnt=200)
      at ../../../../../src/newlib/libc/syscalls/sysread.c:15
  #2  0x40a60b in func_shell (o=0xa01ef28 "", argv=0x24ad07c,
      funcname=0x40a81d "shell")
      at /u/jik/systems-cvs-root/cygwin/make/function.c:1448
  #3  0x40aa39 in expand_builtin_function (o=0xa01ef28 "", argc=1,
      argv=0x24ad07c, entry_p=0x42f0b4)
      at /u/jik/systems-cvs-root/cygwin/make/function.c:1703
  #4  0x40ad20 in handle_function (op=0x24ad160, stringp=0x24ad15c)
      at /u/jik/systems-cvs-root/cygwin/make/function.c:1803
  #5  0x404b53 in variable_expand_string (line=0x0,
      string=0x24ad21c "${shell $(CC_FOR_TARGET) -print-libgcc-file-name}",
      length=-1) at /u/jik/systems-cvs-root/cygwin/make/expand.c:235
  #6  0x404ffe in variable_expand (
      line=0x24ad21c "${shell $(CC_FOR_TARGET) -print-libgcc-file-name}")
      at /u/jik/systems-cvs-root/cygwin/make/expand.c:415
  #7  0x4050d2 in variable_expand_for_file (
      line=0x24ad21c "${shell $(CC_FOR_TARGET) -print-libgcc-file-name}",
      file=0x0) at /u/jik/systems-cvs-root/cygwin/make/expand.c:457
  #8  0x405364 in allocated_variable_expand_for_file (
      line=0x24ad21c "${shell $(CC_FOR_TARGET) -print-libgcc-file-name}",
      file=0x0) at /u/jik/systems-cvs-root/cygwin/make/expand.c:535
  #9  0x4050ab in expand_argument (
      str=0xa01be8c "${shell $(CC_FOR_TARGET) -print-libgcc-file-name}}",
      end=0xa01bebd "}") at /u/jik/systems-cvs-root/cygwin/make/expand.c:442
  #10 0x40acdc in handle_function (op=0x24ad380, stringp=0x24ad37c)
      at /u/jik/systems-cvs-root/cygwin/make/function.c:1791
  #11 0x404b53 in variable_expand_string (line=0x0,
      string=0xa01be80 "${subst \\,/,${shell $(CC_FOR_TARGET) -print-libgcc-file-name}}", length=-1) at /u/jik/systems-cvs-root/cygwin/make/expand.c:235
  #12 0x404ffe in variable_expand (
      line=0xa01be80 "${subst \\,/,${shell $(CC_FOR_TARGET) -print-libgcc-file-name}}") at /u/jik/systems-cvs-root/cygwin/make/expand.c:415
  #13 0x4050d2 in variable_expand_for_file (
      line=0xa01be80 "${subst \\,/,${shell $(CC_FOR_TARGET) -print-libgcc-file-name}}", file=0x0) at /u/jik/systems-cvs-root/cygwin/make/expand.c:457
  #14 0x405364 in allocated_variable_expand_for_file (
      line=0xa01be80 "${subst \\,/,${shell $(CC_FOR_TARGET) -print-libgcc-file-name}}", file=0x0) at /u/jik/systems-cvs-root/cygwin/make/expand.c:535
  #15 0x426757 in try_variable_definition (flocp=0x24ad564,
      line=0xa01be78 "libgcc:=${subst \\,/,${shell $(CC_FOR_TARGET) -print-libgcc-file-name}}", origin=o_file, target_var=0)
      at /u/jik/systems-cvs-root/cygwin/make/variable.c:892
  #16 0x41a13d in read_makefile (
      filename=0xa01b960 "../../../../src/winsup/doc/../Makefile.common",
      flags=10) at /u/jik/systems-cvs-root/cygwin/make/read.c:723
  #17 0x41a076 in read_makefile (filename=0xa01af88 "Makefile", flags=0)
      at /u/jik/systems-cvs-root/cygwin/make/read.c:702
  #18 0x41899e in read_all_makefiles (makefiles=0x0)
      at /u/jik/systems-cvs-root/cygwin/make/read.c:234
  #19 0x413e0c in main (argc=4, argv=0x614f1b9c, envp=0xa010008)
      at /u/jik/systems-cvs-root/cygwin/make/main.c:1503
  #20 0x61004374 in dll_crt0_1 () at ../../../../src/winsup/cygwin/dcrt0.cc:862
  #21 0x61004649 in _dll_crt0 () at ../../../../src/winsup/cygwin/dcrt0.cc:932
  #22 0x61004688 in dll_crt0 (uptr=0x0)
      at ../../../../src/winsup/cygwin/dcrt0.cc:944
  #23 0x42e7d3 in cygwin_crt0 ()

What's going on here is that make.exe calls vfork, then executes a
command in the child, then reads the output of the command in the
parent.

Line 2317 of job.c is make (in the child) trying to print an error
because the exec failed for some reason:

      perror_with_name ("execvp: ", argv[0]);

Alas, as you can see from arguments shown in frame 0 above, argv is
corrupt, so the argv[0] dereference causes a stack trace.  The
question, then, is why is argv[0] corrupt?

What is odd here is that although frame 0 is in the child's code path,
frame 1 is in the parent's code path *after the vfork is supposed to
have finished*.  I don't get how that can be possible.  The way cgf
described how vfork works (and the way it seems to work from my
reading of the code), I thought that control wouldn't be longjmp'd
back to the "parent" vfork process until the child finished.  So how
could post-vfork code in both the parent and the child be executing at
the same time?

If, indeed, the parent's vfork code starts running before the child's
is finished, it's understandable why memory would get corrupted in the
child.  Note, for example, this code that happens in the parent
shortly after the vfork:

      /* Free the storage only the child needed.  */
      free (command_argv[0]);
      free ((char *) command_argv);

I'm having trouble getting any more useful information out of this
process in the debugger.  If nobody has any suggestions in the near
future for what I should do, my next step is going to be to recompile
Make so that it calls perror without trying to use argv[0], so that I
can at least see what error it thinks is preventing the exec after the
vfork from succeeding.

  jik