Rajesh Balakrishnan Wed, 17 Mar 2004 04:21:28 + (UTC)
emacs (under X11) is working fine since Mar 06 snapshot of
cygwin1.dll. http://cygwin.com/snapshots/
Thomas L Roche Wed, 17 Mar 2004 08:00:00 -0500
That has not been my experience: I have been tracking the snapshots,
but my emacs still segfaults, dumps core, etc. Hopefully I will get
a chance to build sources and debug soon.
Just to amplify (though of course what I should be doing is building
cygwin1, xfree86, and emacs from source and debugging--props to Moira
Regelson), here's some more data. Note that I stay pretty current with
both cygwin1.dll and xfree86: presently
$ cygcheck -srv | grep 'cygwin\|XFree86'
1100k 2004/03/16 d:\ProgramFiles\Cygwin\bin\cygwin1.dll - os=4.0
img=1.0 sys=4.0
cygwin1.dll v0.0 ts=2004/3/16 0:19
DLL identifier: cygwin1
Shared id: cygwin1S4
Last downloaded files to: D:\download\cygwin
Last downloaded files from: ftp://mirrors.rcn.net/pub/sourceware/cygwin
cygwin 1.5.8-1
cygwin-doc 1.3-7
XFree86-base4.3.0-7
XFree86-bin 4.3.0-17
XFree86-etc 4.3.0-10
XFree86-fenc4.3.0-1
XFree86-fnts4.3.0-1
XFree86-lib 4.3.0-2
XFree86-lib-compat 4.3.0-2
XFree86-startup-scripts 4.3.0-1
XFree86-xserv 4.3.0-58
The cygwinized GNU Emacs was very stable under X (with -multiwindow
and -clipboard) in 1.5.5-1. Since upgrading from that, I have had
* apparently-random crashes: segfaults, dumps core, etc. Rarely,
but occasionally, the crashes leave cryptic X-related messages in
the console.
* hangs on window modification or creation. Cygwin emacs has actually
been pretty stable since late Feb/early Mar, in that it doesn't
crash very often IFF I don't move, resize, minimize, or create new
windows (e.g. with [C-x 5 f]). If I just startup an xterm, then
startup one (and only one) emacs window and don't touch it, I can
usually get several hours of productive use out of it. But if I do
any of those 4 ops (which I usually did frequently pre-1.5.5-1), it
will almost certainly, within a few minutes, hang without refreshing
its windows: i.e.
· if I drag a non-emacs window over an emacs one, then minimize the
non-emacs one, the area of overlap will be visible as white space on
the emacs window.
· no gesture causes any change in the hung window
· the hung window cannot be closed except by killing the emacs
process
There are other less destructive glitches that have appeared since
1.5.5-1 (e.g. my emacs cursor is normally a blinking solid rectangle,
but if I minimize my emacs window, then restore it, the emacs cursor
becomes a non-blinking rectangular outline, aka the keyhole of
death), but the problems above are the ones that tend to ruin my day.