delorie.com/archives/browse.cgi | search |
Mailing-List: | contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm |
Sender: | cygwin-owner AT sourceware DOT cygnus DOT com |
Delivered-To: | mailing list cygwin AT sourceware DOT cygnus DOT com |
Date: | Sat, 26 Jun 1999 14:02:29 -0400 |
From: | Chris Faylor <cygwin AT sourceware DOT cygnus DOT com> |
To: | cygwin AT sourceware DOT cygnus DOT com |
Subject: | Re: Electric Fence for Cygwin |
Message-ID: | <19990626140229.A816@cygnus.com> |
References: | <19990623103930 DOT A13510 AT ba DOT best DOT com> <37733AD4 DOT EDF0A46C AT st DOT com> <19990625132456 DOT A325 AT ba DOT best DOT com> |
Mime-Version: | 1.0 |
X-Mailer: | Mutt 0.95.3i |
In-Reply-To: | <19990625132456.A325@ba.best.com>; from Glenn Spell on Fri, Jun 25, 1999 at 01:24:56PM -0400 |
On Fri, Jun 25, 1999 at 01:24:56PM -0400, Glenn Spell wrote: >> I have a simple hello-world with a single 'char* >> p=(char*)malloc(10);' line. I compile it with 'gcc hello.c -o >> hello.exe -lefence'. >> >> It crashes with a 'instruction references memory at "0x00000000"' >> error. A simple debug session with gdb shows that it crashes at >> '0x61006cd2 in _size_of_stack_reserve__()', before main. > >I don't understand any of this. I'm not a programmer. I know that the >memory location is related to cygwin. I know that all references I >can find on the net to "_size_of_stack_reserve__()" relate to cygwin >or mingw (and Mumit reads them all!) or some articles on memory >management at Microsoft. Actually this memory location indicates an error that is *not* in cygwin. It seems that gdb spits this out in some circumstances when it doesn't know the symbolic name for an address. gdb should always know symbolic names for addresses in the DLL. cgf -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |