This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: [64bit] emacs-w32 crash
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin-developers at cygwin dot com
- Date: Fri, 5 Apr 2013 16:00:14 +0200
- Subject: Re: [64bit] emacs-w32 crash
- References: <515ED1BE dot 8050408 at cornell dot edu>
- Reply-to: cygwin-developers at cygwin dot com
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