> -----Original Message----- > Of Ken Brown > Sent: Monday, April 21, 2014 4:16 AM > Subject: Re: Fatal error from Cygwin emacs-w32 every day or so > > On 4/21/2014 1:14 AM, KARR, DAVID wrote: > >> -----Original Message----- > >> Of KARR, DAVID > >> Sent: Saturday, April 19, 2014 6:19 PM > >> Subject: RE: Fatal error from Cygwin emacs-w32 every day or so > >> > >>> -----Original Message----- > >>> Of Ken Brown > >>> Sent: Saturday, April 19, 2014 4:38 PM > >>> Subject: Re: Fatal error from Cygwin emacs-w32 every day or so > >>> > >>> On 4/15/2014 12:13 PM, Ken Brown wrote: > >>>> On 4/15/2014 12:12 AM, Eli Zaretskii wrote: > >>>>>> Date: Mon, 14 Apr 2014 21:08:15 -0700 > >>>>>> From: Ken Brown > >>>>>> > >>>>>>> I just saw it die, and this is the bt I get: > >>>>>>> > >>>>>>> Program received signal SIGSEGV, Segmentation fault. > >>>>>>> 0x0000000100551354 in wait_reading_process_output ( > >>>>>>> time_limit=time_limit@entry=0, nsecs=nsecs@entry=0, > >>>>>>> read_kbd=read_kbd@entry=-1, > do_display=do_display@entry=true, > >>>>>>> wait_for_cell=wait_for_cell@entry=4304630834, > >>>>>>> wait_proc=wait_proc@entry=0x0, > >>>>>>> just_wait_proc=just_wait_proc@entry=0) > >>>>>>> @/usr/src/debug/emacs-24.3-7/src/process.c:4677 > >>>>>>> 4677 if (wait_proc->gnutls_p /* Check for > >> valid > >>>>>>> process. */ > >>>>>> > >>>>>> This backtrace doesn't make sense. If you look at the source code, > >>>>>> you'll see that if wait_proc is NULL on entry to > >>>>>> wait_reading_process_output, then line 4677 is never reached. I'm > >> not > >>>>>> sure what would cause a bogus backtrace like this. BLODA? > >>>>>> Optimization? > >>>>>> > >>>>>> In any case, I suggest that you wait a week until I have a chance > to > >>>>>> build a pretest of 24.4 for you to try. I'll build it without > >>>>>> optimization to make debugging easier. > >>>>> > >>>>> This is a known problem with GnuTLS support, it was solved in the > >>>>> Emacs repository last November (bzr revision 114956, if someone > wants > >>>>> the diffs), and surely should be solved in the upcoming Emacs 24.4. > >>>> > >>>> Thanks, Eli! In that case I'll make a new release of emacs-24.3 with > >>>> that patch applied, to see if it resolves the issue for the OP. > >>> > >>> I've rebuilt emacs-24.3 with the gnutls fix. David and Achim (and > >>> anyone else who's been experiencing these crashes), please try the > >>> following binary and let me know if it solves the problem: > >>> > >>> http://sanibeltranquility.com/cygwin/emacs-w32.exe.xz > >>> > >>> You might have to do "chmod +x emacs-w32.exe" after uncompressing it. > >>> > >>> If it fixes the problem, I'll issue a new release of emacs-24.3. If > >>> not, I'll build a pretest of emacs-24.4 for you to try. > >> > >> Ok. It's running. As it only fails after random intervals, I'll have > to > >> keep it running for a while. I'll give it a day or so. > > > > I came back to my computer and saw two dialogs, one saying that my VPN > connection had died (that happens from time to time), and the other the > Emacs failure dialog. I started this executable from gdb, but it's saying > that it doesn't have symbols, so the stacktrace probably isn't helpful, > but this is what I saw: > > Right. I just supplied a stripped binary for a quick test. It's not > suitable for debugging. > > > I've started it again, but not in gdb this time. > > If it crashes again, I'll build a pretest of 24.4 without optimization > and issue it as a test release.
It just failed again while sitting here in my office (no relation to VPN/network issues). -- 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