Mail Archives: cygwin-developers/2002/01/10/16:47:56

Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
Date: Thu, 10 Jan 2002 16:47:55 -0500
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: Re: Am I using dumper.exe correctly?
Message-ID: <>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT cygwin DOT com
References: <20020110214350 DOT 30413 DOT qmail AT lizard DOT curl DOT com>
Mime-Version: 1.0
In-Reply-To: <>
User-Agent: Mutt/

I don't know why cygwin is crashing (obviously) or why the core
file support isn't working.  I think others have reported similar
problems, though.  Maybe Egor will offer some insight here.

It might be helpful to build a gdb from cvs.
There may be some fixes there that are not in the released version.
I should, in fact, look into making a new release since I think
all of the sticky tcl/tk issues that were causing problems before
have been rectified.

Is there a .stackdump file being created?  You can use addr2line
or gdb to figure out where the crash is occuring from that.
It won't be as informative as gdb, of course, but it might be
a start.


On Thu, Jan 10, 2002 at 04:43:50PM -0500, Jonathan Kamens wrote:
>We're using cygwin-1.3.6-6 on our build servers and current versions
>of just about all the other packages.  We get occasional crashes in
>cygwin processes during our automated builds, so I decided to debug
>them as follows:
>1) Build the current CVS repository configured like this:
>   CFLAGS="-g -O" configure --enable-threadsafe \
>     --enable-extra-threadsafe-checking --enable-debugging \
>     --enable-vfork
>2) Install the new-cygwin1.dll built above on our build servers as
>   cygwin1.dll.
>3) Put "error_start=c:\cygwin\bin\dumper.exe" in the CYGWIN
>   environment variable.
>4) Run builds until we get a coredump.
>5) Debug the coredump with gdb -- "gdb -nw foo.exe foo.exe.core".
>However, I ran into a few problems (obviously, or I wouldn't be
>sending this message :-):
>1) Things run Very Slowly with the new version of cygwin1.dll.  If I
>   had to guess, I'd guess that --enable-extra-threadsafe-checking is
>   probably the culprit.  Can anybody confirm or deny that?
>2) To test that things were working as expected, I compiled and ran
>   this program:
>     main() {
>       char *foo = 0;
>       foo[0] = '\0';
>     }
>   It did, indeed, crash and produce the file a.exe.core when I ran
>   it.  However, when I tried to run "gdb -nw a.exe a.exe.core", it
>   coredumped too.  Note that when I run "gdb -nw a.exe" and type
>   "run", it correctly runs the program and shows me that the program
>   segfaulted on the assignment line; it apparently only coredumps
>   when a core file from dumper is specified on the command line.  It
>   also coredumps if I run "gdb -nw a.exe" and then specify "core
>   a.exe.core".
>My next step will be to recompile gdb with debugging symbols and run
>gdb under gdb to try to figure out why it's coredumping.  Before I go
>ahead with that, does anybody have any insights into what I might be
>doing wrong or any other suggestions?
>  jik

cgf AT redhat DOT com                        Red Hat, Inc.  

- Raw text -

  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019