This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: 64-bit emacs crashes a lot
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Fri, 2 Aug 2013 10:02:11 +0200
- Subject: Re: 64-bit emacs crashes a lot
- References: <51F3151D dot 7040000 at cs dot utoronto dot ca> <51F33565 dot 1090406 at cornell dot edu> <51F33F52 dot 4060405 at cs dot utoronto dot ca> <51FB1D9E dot 5090102 at cs dot utoronto dot ca>
- Reply-to: cygwin at cygwin dot com
On Aug 1 22:46, Ryan Johnson wrote:
> On 26/07/2013 11:32 PM, Ryan Johnson wrote:
> >On 26/07/2013 10:50 PM, Ken Brown wrote:
> >>On 7/26/2013 8:32 PM, Ryan Johnson wrote:
> >>>Hi all,
> >>>
> >>>Running 64-bit cygwin 1.7.22(0.268/5/3), with emacs-nox 24.3-4 inside
> >>>mintty 1.2-beta1-1, I keep getting seg faults and "Fatal error
> >>>6: Aborted"
> >
> >>>It happens at strange times, invariably during I/O of some kind (either
> >>>keyboard input or output from some compilation window); I don't get the
> >>>impression it's fork-related. I don't know how to get a backtrace from
> >>>emacs, given the way any exception or signal always loses the
> >>>"userland"
> >>>stack (suggestions welcome).
> >>>
> >>>Anyone else seeing this?
> >>
> >>This doesn't really answer your question since I don't use
> >>emacs-nox, but I've been running 64-bit emacs-X11 and finding it
> >>very stable. I typically keep it running for several days at a
> >>time.
> >>
> >>You say you don't know how to get a backtrace from emacs. I
> >>assume you've installed emacs-debuginfo and run emacs under gdb.
> >>Are you saying you can never get a backtrace after it crashes?
> >I do have the emacs-debuginfo. I meant that the stack dump didn't
> >have any emacs frames in it (they were all cygwin1.dll), and my
> >experience with cygwin/gdb is that once you've taken a signal or
> >exception you lose the cygwin stack and just see a bunch of
> >threads mucking around in various low-level Windows dlls.
> >
> >I have tried attaching gdb to emacs and setting a breakpoint on
> >abort(), but it didn't catch anything yet. I'm also hampered by
> >gdb constantly getting confused, breaking partway into emacs, and
> >having to detach/reattach it. I've started a new thread for that
> >issue.
>
> Here's a new one... I started a compilation, but before it actually
> invoked the command it started pegging the CPU. After ^G^G^G, it
> crashed with the following:
> >Auto-save? (y or n) y
> > 0 [main] emacs 5076 C:\cygwin64\bin\emacs-nox.exe: *** fatal
> >error - Internal error: TP_NUM_W_BUFS too small 2268032 >= 10.
That looks like a memory overwrite. 2268032 is 0x229b80, which looks
suspiciously like a stack address. And the overwritten value is on the
stack, too, well within the cygwin TLS area. If *this* value gets
overwritten, the TLS is probbaly totally hosed at this point. There's
just no way to infer the culprit from this limited info.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple