Mailing-List:	contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT sources DOT redhat DOT com>
List-Help:	<mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT sources DOT redhat DOT com
Delivered-To:	mailing list cygwin AT sources DOT redhat DOT com
From:	Chris Faylor <cgf AT cygnus DOT com>
Date:	Sat, 7 Oct 2000 18:43:49 -0400
To:	cygwin <cygwin AT sources DOT redhat DOT com>
Subject:	Re: Creating core dumps and gdb tracing...
Message-ID:	<20001007184349.A31402@cygnus.com>
Reply-To:	cygwin AT sources DOT redhat DOT com
Mail-Followup-To:	cygwin <cygwin AT sources DOT redhat DOT com>
References:	<002201c030af$b80e0330$1605a018 AT austin DOT rr DOT com>
Mime-Version:	1.0
User-Agent:	Mutt/1.3.6i
In-Reply-To:	<002201c030af$b80e0330$1605a018@austin.rr.com>; from scain1@austin.rr.com on Sat, Oct 07, 2000 at 05:41:22PM -0500

On Sat, Oct 07, 2000 at 05:41:22PM -0500, Shelby Cain wrote:
>Consider a simple program like so:
>
>int main()
>{
>    char * foo = 0;
>    crashme(foo);
>}
>
>int crashme(char * cp);
>{
>    strcpy(cp, "KABOOM!!");
>}
>
>Compiling and linking it under W2K using cygwin produces an executable that
>does not produce a core file when it crashes.  One way around this would be
>to run it via gdb (ie: gdb crashme.exe) which will allow me to catch the
>offending statement.  However, I would really prefer a core file to work
>with as I don't have to "recreate" the situation in order to see what is
>going on.
>
>Regardless, when I use gdb to catch the seg fault... the stack window isn't
>providing me with any useful information.  When I open up the gdb console
>and try "backtrace" I get something to the effect of:
>
>"Error: #0  0x61070850 in _size_of_stack_reserve__ ()
>Cannot access memory at address 0x2000000"

You're probably not in thread 1.  cygwin is multi-threaded.  The main thread
is usually thread 1.

Type "thread 1" command in gdb and then see if 'bt' shows anything.  If it
doesn't, it's probably because most Microsoft API functions don't have a
frame pointer.  If you're stuck in one of those, then the stack will be
screwed up.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com

- Raw text -