This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: malloc failure - segfault in random ()


> -----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@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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]