64-bit emacs crashes a lot
Fri Aug 2 08:02:00 GMT 2013
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
> >>>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
> >>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
> 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 Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin