Known Problems with GNU Emacs
-Copyright (C) 1987, 1988, 1989, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
- 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
+Copyright (C) 1987-1989, 1993-1999, 2001-2012
Free Software Foundation, Inc.
See the end of the file for license conditions.
The following command will print any duplicate Lisp files that are
present in load-path:
- emacs -q -batch -f list-load-path-shadows
+ emacs -batch -f list-load-path-shadows
If this command prints any file names, some of these files are stale,
and should be deleted or their directories removed from your
CFLAGS="-g -O2 -fno-optimize-sibling-calls" ./configure
+** Emacs compiled with GCC 4.6.1 crashes on MS-Windows when C-g is pressed
+
+This is known to happen when Emacs is compiled with MinGW GCC 4.6.1
+with the -O2 option (which is the default in the Windows build). The
+reason is a bug in MinGW GCC 4.6.1; to work around, either add the
+`-fno-omit-frame-pointer' switch to GCC or compile without
+optimizations (`--no-opt' switch to the configure.bat script).
+
** Emacs crashes in x-popup-dialog.
This can happen if the dialog widget cannot find the font it wants to
On platforms such as Solaris, you can also work around this problem by
configuring your compiler to use the native linker instead of GNU ld.
-** Emacs compiled with Gtk+ crashes when closing a display (x-close-connection).
+** When Emacs is compiled with Gtk+, closing a display kills Emacs.
-This happens because of bugs in Gtk+. Gtk+ 2.10 seems to be OK. See bug
-http://bugzilla.gnome.org/show_bug.cgi?id=85715.
+There is a long-standing bug in GTK that prevents it from recovering
+from disconnects: http://bugzilla.gnome.org/show_bug.cgi?id=85715.
-** Emacs compiled with Gtk+ may loop forever if a display crashes.
+Thus, for instance, when Emacs is run as a server on a text terminal,
+and an X frame is created, and the X server for that frame crashes or
+exits unexpectedly, Emacs must exit to prevent a GTK error that would
+result in an endless loop.
-This is related to the bug above. A scenario for this is when emacs is run
-as a server, and an X frame is created. If the X server for the frame
-crashes or exits unexpectedly and an attempt is made to create a new
-frame on another X display, then a Gtk+ error happens in the emacs
-server that results in an endless loop. This is not fixed in any known
-Gtk+ version (2.14.4 being current).
+If you need Emacs to be able to recover from closing displays, compile
+it with the Lucid toolkit instead of GTK.
* General runtime problems
the `flock' system call. The other involves creating a lock file;
`movemail' must be able to write in /usr/spool/mail in order to do
this. You control which one is used by defining, or not defining,
-the macro MAIL_USE_FLOCK in config.h or the m- or s- file it includes.
+the macro MAIL_USE_FLOCK in config.h or the m/ or s/ file it includes.
IF YOU DON'T USE THE FORM OF INTERLOCKING THAT IS NORMAL ON YOUR
SYSTEM, YOU CAN LOSE MAIL!
** Miscellaneous problems
+*** Editing files with very long lines is slow.
+
+For example, simply moving through a file that contains hundreds of
+thousands of characters per line is slow, and consumes a lot of CPU.
+This is a known limitation of Emacs with no solution at this time.
+
*** Emacs uses 100% of CPU time
This is a known problem with some versions of the Semantic package.
2) If the connection is very slow, you might also want to consider
switching off scroll bars, menu bar, and tool bar. Adding the
following forms to your .emacs file will accomplish that, but only
- after the the initial frame is displayed:
+ after the initial frame is displayed:
(scroll-bar-mode -1)
(menu-bar-mode -1)
4) Use lbxproxy on the remote end of the connection. This is an interface
to the low bandwidth X extension in most modern X servers, which
improves performance dramatically, at the slight expense of correctness
- of the X protocol. lbxproxy acheives the performance gain by grouping
+ of the X protocol. lbxproxy achieves the performance gain by grouping
several X requests in one TCP packet and sending them off together,
instead of requiring a round-trip for each X request in a separate
packet. The switches that seem to work best for emacs are:
exec 2> >(exec cat >&2 2>/dev/null)
exec ssh "$@"
+*** GNU/Linux: Truncated svn annotate output with SSH.
+http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7791
+
+The symptoms are: you are accessing a svn repository over SSH.
+You use vc-annotate on a large (several thousand line) file, and the
+result is truncated around the 1000 line mark. It works fine with
+other access methods (eg http), or from outside Emacs.
+
+This may be a similar libc/SSH issue to the one mentioned above for CVS.
+A similar workaround seems to be effective: create a script with the
+same contents as the one used above for CVS_RSH, and set the SVN_SSH
+environment variable to point to it.
+
*** GNU/Linux: On Linux-based GNU systems using libc versions 5.4.19 through
5.4.22, Emacs crashes at startup with a segmentation fault.
But in some of the cases listed above, this problem is a consequence
of something else that is wrong. Be sure to check and fix the real problem.
-*** Linux: Emacs crashes when dumping itself on Mac PPC running Yellow Dog GNU/Linux.
-
-The crashes happen inside the function Fmake_symbol; here's a typical
-C backtrace printed by GDB:
-
- 0x190c0c0 in Fmake_symbol ()
- (gdb) where
- #0 0x190c0c0 in Fmake_symbol ()
- #1 0x1942ca4 in init_obarray ()
- #2 0x18b3500 in main ()
- #3 0x114371c in __libc_start_main (argc=5, argv=0x7ffff5b4, envp=0x7ffff5cc,
-
-This could happen because GCC version 2.95 and later changed the base
-of the load address to 0x10000000. Emacs needs to be told about this,
-but we currently cannot do that automatically, because that breaks
-other versions of GNU/Linux on the MacPPC. Until we find a way to
-distinguish between the Yellow Dog and the other varieties of
-GNU/Linux systems on the PPC, you will have to manually uncomment the
-following section near the end of the file src/m/macppc.h in the Emacs
-distribution:
-
- #if 0 /* This breaks things on PPC GNU/Linux except for Yellowdog,
- even with identical GCC, as, ld. Let's take it out until we
- know what's really going on here. */
- /* GCC 2.95 and newer on GNU/Linux PPC changed the load address to
- 0x10000000. */
- #if defined __linux__
- #if __GNUC__ > 2 || (__GNUC__ == 2 && __GNUC_MINOR__ >= 95)
- #define DATA_SEG_BITS 0x10000000
- #endif
- #endif
- #endif /* 0 */
-
-Remove the "#if 0" and "#endif" directives which surround this, save
-the file, and then reconfigure and rebuild Emacs. The dumping process
-should now succeed.
-
*** OpenBSD 4.0 macppc: Segfault during dumping.
The build aborts with signal 11 when the command `./temacs --batch
initialized variables. Emacs makes all initialized variables in most
of its files pure after dumping, but the variables declared static and
not initialized are not supposed to be pure. On these systems you
-may need to add "#define static" to the m- or the s- file.
+may need to add "#define static" to config.h.
* Runtime problems on legacy systems
mode: outline
paragraph-separate: "[ \f]*$"
end:
-
-arch-tag: 49fc0d95-88cb-4715-b21c-f27fb5a4764a
HCoop / bpt / emacs.git / blobdiff