> -----Original Message----- > Of KARR, DAVID > Sent: Monday, April 21, 2014 7:21 PM > Subject: RE: Fatal error from Cygwin emacs-w32 every day or so > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > > -----Original Message----- > > Of Ken Brown > > Sent: Monday, April 21, 2014 11:34 AM > > Subject: Re: Fatal error from Cygwin emacs-w32 every day or so > > > > On 4/21/2014 1:25 PM, KARR, DAVID wrote: > > >> -----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). > > > > Could you try one more thing if you haven't already: Start emacs with > > the -Q option, in case there's something in your initialization files > > that triggers the problem. > > I started both a regular instance and the "-Q" instance around noon today > (7 hours ago). The regular instance failed once since then, which I > restarted. The Q instance hasn't failed yet. That's not a definite, but > it's lasted longer so far. Note that I haven't changed my .emacs in a > very long time.
The regular instance has failed several times in the last couple of days, whereas the "-Q" one still hasn't failed once. -- 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
