RE: seg fault via cygwin1!aclcheck() ?

["Dave Korn" <dk at artimi dot com>]

> -----Original Message-----
> From: cygwin-owner On Behalf Of Larry Hall
> Sent: 18 April 2004 23:56

> >I am running ns on cygwin, and after my program executes for 
> a while with no
> >problems, suddenly I get a seg fault with the following 
> backtrace (in gdb):
> >
> >Program received signal SIGSEGV, Segmetation fault.
> >0x610ab27b in random () from /usr/bin/cygwin1.dll
> >(gdb) backtrace
> >#0 0x610ab27b in random () from /usr/bin/cygwin1.dll
> >#1 0x610550c6 in localtime_r () from /usr/bin/cygwin1.dll
> >#2 0x61086751 in cygwin1!aclcheck () from /usr/bin/cygwin1.dll
> >...(the rest of the trace is from my ns code)

  That would have perhaps been the more informative bit.  If there's a crash
in the .dll, it's most usually because your code has made a system call with
bad arguments, such as an invalid pointer.

> >What is wrong? It seems like a permissions problem, but my 
> code is not writing
> >to a file. Although my code reads from a file, this seg 
> fault occurs after a
> >great many lines have been already read from this file. 
> Based on the back
> >trace, the seg fault does not occur at a point where the 
> file is read anyway. 
> >
> >How can I fix this?
> 
> 
> Looks like you're going to have to break out the debugger.  
> aclcheck() 
> doesn't call localtime_r() (or anything close to it) 

  Not only does aclcheck not call localtime_r, but I'd be *really*
interested to know what reason localtime_r could *ever* have for calling
random........ 

> so this leads me to 
> conclude that you have a stack corruption in your program somewhere.

  It's not necessarily even that at all; it's just that a non-debug build of
the .dll only contains symbols for the exported entry points.  All the
internal functions that have no external linkage (static functions in C
terms; file-scope in C++) aren't declared.  So there are only intermittent
symbols to mark points throughout the code in the .dll.  The function names
you see in the backtrace are misleading: gdb looks backward from the
recorded value of eip to find the nearest symbol that's declared, but it's
not smart enough to know that if it's stepped backwards over a return
instruction it must have backed up into a completely different subroutine.

  Without a full debug build of the .dll, stacktracebacks are essentially
worthless.  Sorry, that's imprecise, let me correct myself:  Without a full
debug build of the .dll, the part of the traceback showing stack frames for
functions inside the .dll is worthless, and without a full debug build of
the application, the subsequent part of the traceback showing the stack
frame chain through the functions in the application is worthless.  (Or very
very close to worthless).


    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/