Mail Archives: cygwin/2014/04/21/22:21:53
> -----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 AT entry=0, nsecs=nsecs AT entry=0,
> >>>>>>>>> read_kbd=read_kbd AT entry=-1,
> >> do_display=do_display AT entry=true,
> >>>>>>>>> wait_for_cell=wait_for_cell AT entry=4304630834,
> >>>>>>>>> wait_proc=wait_proc AT entry=0x0,
> >>>>>>>>> just_wait_proc=just_wait_proc AT 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.
--
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
- Raw text -