On Aug 2 10:53, Ken Brown wrote: > On 8/1/2012 8:58 AM, Corinna Vinschen wrote: > >On Aug 1 08:46, Ken Brown wrote: > >>I never had a reliable way of reproducing the crash (see > >>http://cygwin.com/ml/cygwin/2012-06/msg00464.html). It happened > >>seemingly at random, and very sporadically. But I have the snapshot > >>installed and will exercise it as much as I can. > > > >Thanks! > > The good news: I haven't seen a repeat of that old crash so far.
That's really good news, thank you. > Unfortunately, I'm finding that emacs is unstable: The emacs window > (running under X) simply disappears after 12-24 hours. This may not > have anything to do with the most recent changes. I haven't yet > tested any earlier snapshots. > > Testing this is a very slow process, since I don't know how to > produce the problem; I just have to wait and see if emacs will die. > > I tried to get some information by running emacs under gdb the most > recent time I started it, but all I got was this: > > (gdb) c > Continuing. > [Inferior 1 (process 8196) exited with code 05400] > (gdb) bt > No stack > > Does that exit code mean anything to you? I couldn't find anything > by googling. 05400 oct is 0xb00 hex. As a wait(2) compatible exit code, it would mean a normal exit, not signal-induced, with an exit value of 11. Which is kind of suspicious, since 11 is also the signal number of a SEGV. Of course, not every SEGV must be related to the problem at hand, but still... Does emacs have a signal handler which handles SEGVs? If so, you might consider to set a breakpoint on this signal handler in GDB. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader 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
