Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com From: "Dave Korn" To: Subject: RE: malloc failure - segfault in random () Date: Thu, 19 Aug 2004 10:35:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <41245B9E.4040001@ucsc.edu> Message-ID: X-OriginalArrivalTime: 19 Aug 2004 09:35:52.0062 (UTC) FILETIME=[EB0081E0:01C485CF] > -----Original Message----- > From: cygwin-owner On Behalf Of Charles Notley > Sent: 19 August 2004 08:50 > My application successfully allocates memory > many times, then segfaults when mallocing a new struct: > > assert((N=(SymbolNode*)malloc(sizeof(SymbolNode)))!=NULL); Then you've overwritten the end of a previously malloced block (or written before the start; either way, you've scribbled on the heap). > It runs correctly on a Sun system Just luck; different memory layout, different heap structures, different allocation granularities mean that whatever stray pointer you have is hitting somewhere harmless in a Sun process layout and harmful in a win32 process layout. > My conclusion is that either I'm doing something wrong or > there's a bug in the cygwin.dll It's 99% likely you have a stray pointer bug in your code; you'll need to show better evidence before this becomes other than the most likely possibility. > /* > * information from GDB > */ > Program received signal SIGSEGV, Segmentation fault. > 0x610b446b in random () from /usr/bin/cygwin1.dll > (gdb) info thread > 2 thread 3168.0xc4c 0x7ffe0304 in ?? () > * 1 thread 3168.0xb78 0x610b446b in random () from > /usr/bin/cygwin1.dll > (gdb) backtrace > #0 0x610b446b in random () from /usr/bin/cygwin1.dll > #1 0x6105c476 in dll_entry AT 12 () from /usr/bin/cygwin1.dll > #2 0x6108df2f in cygwin1!aclcheck () from /usr/bin/cygwin1.dll > #3 0x00403400 in internSymbolTable (S=0xa05bbe0, > t=0xa056828, a=2060, s=0, > flag=0x22ef84, params=0x0) at symboltable.c:243 > #4 0x004042d3 in declare (root=0xa056828, attrib=2060, paramNum=0, > paramPtr=0xa0568d8) at tokenast.c:266 > #5 0x00404596 in buildSymbolTable (t=0xa051ed0, flag=0) at > tokenast.c:305 > #6 0x004018ad in main (argc=3, argv=0xa051138) at main.c:145 The stack backtrace is only accurate in your own program code, because you built your program with debug info. The cygwin dll doesn't have debug info in it, so the function names are pretty much guesswork, based on the nearest exported symbol. After all, you called malloc, not aclcheck! And nothing should be calling through dll_entry! So I don't reckon it was really in random either. I reckon it's in some internal heap management functions that were declared 'static' in C so the symbols aren't exported. cheers, DaveK -- Can't think of a witty .sigline today.... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/