Mail Archives: cygwin/2004/08/19/05:38:59
> -----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/
- Raw text -