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
