emacs-w32 24.5.1: Crashes with --daemon and in "About Emacs"

Ken Brown kbrown@cornell.edu
Mon May 18 13:43:00 GMT 2015


On 5/18/2015 1:57 AM, Martin Anantharaman wrote:
> Ken,
>
> so that we do not get side-tracke by differences in our emacs-customizations
> I now re-produced the error in a "clean" environment, i.e. I unset
> ALTERNATE_EDITOR and did the following:

Did you also make sure that EMACS_SERVER_FILE was not set?

> $ emacs --daemon -Q
> Starting Emacs daemon.
>
> $ emacsclient .shrc
> Waiting for Emacs...
> *ERROR*: Could not open file: /dev/cons1

So this time emacsclient did not complain that it couldn't find the socket.  But 
why is it trying to open /dev/cons1?  Are you running these commands in a 
Windows console rather than a Cygwin Terminal (mintty)?  If so, please try it in 
a Cygwin Terminal.

> $ emacsclient .shrc
> Waiting for Emacs...
>
> (emacsclient returns immediately, task-manager shows there is no more
> emacs-w32 process and there is a new stackdump in the working directory)
>
> $ cat emacs-w32.exe.stackdump
> Stack trace:
> Frame     Function  Args
> 017075E4  61033210 (00000558, 0000EA60, 000000A4, 01707654)
> 01707714  610EF12F (00000012, 00000000, 0170776C, 6110E4AF)
>
> To get some more insight I tried to do the same on another machine running
> Arch Linux (though with emacs 24.3 under LXDE) and guess what: At any number
> of calls to emacsclient as above a (emacs-)window is opened in the TERMINAL
> from which I run emacsclient (though a new desktop-window is opened when
> emacsclient is called with the -c option) - which is not working in my
> Cygwin/Windows combination giving the error "*ERROR*: Could not open file:
> /dev/cons1" and crashing emacs on the next c.
>
> So what happends when you call emacs and then emacsclient in the same order
> as shown?

I get the Linux behavior that you just described.

> Regarding the 2. problem (crash on About Emacs) it happens exactly the same
> way when I call emacs with emacs -Q and immediately open About Emacs. I will
> get the debuginfo and try to see where/why it is crashing when I have a
> little spare time - I was just hoping that the stackdump I had attached
> before might actually allow you to localize the error.

The two addresses shown in the stackdump (in the "Function" column) are both in 
cygwin1.dll.

$ addr2line -e /usr/lib/debug/usr/bin/cygwin1.dbg 61033210
/usr/src/debug/cygwin-2.0.2-1/winsup/cygwin/exceptions.cc:1540

$ addr2line -e /usr/lib/debug/usr/bin/cygwin1.dbg 610EF12F
/usr/src/debug/cygwin-2.0.2-1/winsup/cygwin/sigproc.cc:714

This doesn't tell us anything about what was happening in emacs.

Ken

P.S. Please *reply* to my message rather than starting a new message each time, 
so that you preserve the threading in the archives.

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



More information about the Cygwin mailing list