Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Date: 11 Sep 2001 20:16:50 -0400
Message-ID: <20010912001650.20683.qmail@lizard.curl.com>
From: Jonathan Kamens <jik AT curl DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: make.exe stackdump from "make -j2" with current CVS source

To date, we've been using 1.1.8 in-house.  I decided to compare the
performance on a dual-processor machine of 1.1.8 with the
soon-to-be-released 1.3.3 to see whether it got better or worse, so I
set out to time "configure" followed by "make -j2" in a fresh cygwin
build tree with both 1.1.8 and 1.3.3.

Alas, I got a make.exe stackdump when I tried this with 1.3.3.  Using
the instructions recently provided by Corinna for getting something
useful out of a stackdump, I asked gdb to disassemble each of the
function addresses in the stackump to find out what function they were
in.  It didn't seem to provide anything that I can interpret
usefully.  Here's the stackump file, with the function name as spit
out by gdb added in the final column:

  Exception: STATUS_ACCESS_VIOLATION at eip=0040D5EF
  eax=00000004 ebx=614E1BE4 ecx=61098838 edx=0242D298 esi=FFFFFFFF edi=00000000
  ebp=0242D2D4 esp=0242D2A4 program=C:\cygwin\bin\make.exe
  cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
  Stack trace:
  Frame     Function  Args
  0242D2D4  0040D5EF  (00000008, 0A01DDB0, 000000C8, 00408BAE) _size_of_heap_reserve__
  0242D2F4  610822D2  (00000008, 0A01DDB0, 000000C8, 00408BDE) read
  0242D384  00408BFB  (0A01C9C8, 0242D3CC, 00408D8E, 004045F2) _size_of_heap_reserve__
  0242D3B4  00408F25  (0A01C9C8, 00000001, 0242D3CC, 004260B4) ""
  0242D414  00409149  (0242D47C, 0242D480, 00000000, 00403F3D) ""
  0242D494  00403FFA  (00000000, 0A01C0D0, FFFFFFFF, 00404636) ""
  0242D4B4  004045AA  (0A01C0D0, 00000004, 0242D504, 0041DAC8) ""
  0242D4E4  00404636  (0A01C0D0, 00000000, 0242D534, 610802A4) ""
  0242D514  004048A6  (0A01C0D0, 00000000, 00000006, 0041EA64) ""
  0242D574  0041EB57  (0242D64C, 0A01C0C8, 00000002, 00000000) ""
  0242D664  00414F1D  (0A01BA90, 0000000A, 00000007, 00000000) ""
  0242D754  00414E7C  (004139D5, 00000000, 0242D7A4, 00421331) ""
  0242D7A4  00413BAE  (00000000, 00000000, 0242FEB4, 0041048B) ""
  0242FEB4  004104C7  (00000004, 614E1B9C, 0A010008, 00000000) ""
  0242FF10  61003FFE  (00000000, 0A015000, 02000000, FFDFF4E4) dll_crt0_1__Fv
  0242FF40  610041FD  (0040F860, 0A015000, 855EA180, 800654E0) _dll_crt0
  End of stack trace (more stack frames may be present)

I'm going to recompile the dll with --enable-debugging, install
dumper.exe, set error_start, and run builds continuously overnight to
see if I can get it to crash again.  If so, perhaps I'll be able to
debug more usefully with the dump.  Any other suggestions?

  jik