delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/1999/06/26/14:02:08

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

- Raw text -


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