This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fatal error from Cygwin emacs-w32 every day or so


On 4/23/2014 10:03 AM, KARR, DAVID wrote:
-----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.

OK, we've made progress. The next step is to bisect your .emacs and find what it is that's triggering the failure. You might have to also check your site-lisp directories (/usr/share/emacs/site-lisp and /usr/share/emacs/24.3/site-lisp) if you've done any customization in them.

Ken

--
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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]