This is the mail archive of the cygwin-developers 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: [64bit] emacs-w32 crash


On Apr  5 09:29, Ken Brown wrote:
> Now that emacs-nox seems to be working OK, I'm beginning to test emacs-w32 and emacs-X11 (not yet uploaded to the 64-bit release).  emacs-w32 crashed overnight with the following stackdump:
> 
> Stack trace:
> Frame        Function    Args
> 00000223740  0018006E4ED (000002236B8, 000DF0DF046, 00000000000, 00000000000)
> 00000223740  0018006F9CD (00000000000, 00000000000, 00000000358, 00000000000)
> 000002238B0  001801181D8 (000002239F0, 000002239F0, 0010053D66C, 00000223B20)
> 000000000C1  0018011572E (00000000000, 00000000000, 00000000000, 00000000000)
> 00000223C60  00180115BFB (00000000002, 00000223C58, 00180139E88, 0000000000B)
> 00000223C60  00180115DCC (00000223C58, 00000000000, 001005625F8, 00000000000)
> 00000223C60  00180111830 (00000000000, 001005625F8, 00000000000, 00000000400)
> 00000223C60  00100000002 (001005625F8, 00000000000, 00000000400, 00000223C90)
> 00000223C60  00000223C58 (001005625F8, 00000000000, 00000000400, 00000223C90)
> End of stack trace
> 
> Running the top 7 function addresses through addr2line gives
> 
> /ext/redhat/x86_64-pc-cygwin/x86_64-pc-cygwin/include/w32api/winnt.h:1677
> /usr/src/debug/cygwin-1.7.18-16/winsup/cygwin/exceptions.cc:1413
> /usr/src/debug/cygwin-1.7.18-16/winsup/cygwin/sigproc.cc:730
> /usr/src/debug/cygwin-1.7.18-16/winsup/cygwin/signal.cc:248
> /usr/src/debug/cygwin-1.7.18-16/winsup/cygwin/pinfo.h:171
> /usr/src/debug/cygwin-1.7.18-16/winsup/cygwin/signal.cc:285
> fake:?
> 
> I don't know if there's anything you can do with this information, and I'm not asking for debugging help at this early stage.  But I just thought I'd pass it along in case it points to a Cygwin bug.

So, so.  The winnt.h entry is a call to __readgsdword, which should only
happen when trying to access data in the TEB.  The address in exceptions.cc
is basically the call of a signal handler, but this code does not access
the TEB, so the stack is partially scrambled.  The TEB is accessed in the
Cygwin function wrappers handling signals, though.  Maybe this information
is just missing here.  The pinfo.h line is weird.  That's the pinfo
destructor.  In theory this can only crash if the destructor is called
after "this" points into nirvana.  The final signal.cc address is just a
call to raise(2).  Nothing dramatic, in theory.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat


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