XEmacs 21.4.11 "Native Windows TTY Support".
[chise/xemacs-chise.git.1] / PROBLEMS
index ccce14f..5ef0d6a 100644 (file)
--- a/PROBLEMS
+++ b/PROBLEMS
@@ -685,6 +685,63 @@ microsoft website.
 * Problems with running XEmacs
 ==============================
 ** General
+
+*** XEmacs crashes mysteriously.
+
+Check whether XEmacs was configured --use-union-type.  Many compilers
+are known to treat union types incompatibly with proper functioning of
+the Lisp_Object type.  (Whether this is a compiler bug or nonstandard-
+conforming code in XEmacs is a moot point.)  Especially with
+--with-mule, --pdump, and/or non-null --error-checking, this is known
+to produce an unreliable build with many versions of MS VC++ and GCC,
+and similar problems are likely to occur with other compilers.
+
+Symptoms are similar to garbage collection and other "wild pointer"
+bugs, ie, stack-smashing and other hard-to-debug crashes in unrelated
+code.  Try reconfiguring and building without --use-union-type.
+
+--use-union-type _is_ useful to get improved _static_ type checking of
+Lisp objects.  It is theoretically possible that it might help with
+aliasing bugs under optimization and improve runtime stability, but in
+practice exactly the opposite seems to be true.  If you don't work on
+XEmacs C code directly, then avoid --use-union-type entirely for now.
+
+*** XEmacs crashes mysteriously in regexp-intensive applications (eg, Gnus)
+
+The regexp implementation used in XEmacs uses alloca by default for
+efficiency.  alloca provides no reliable way to check for out of
+memory (in this case, stack).  Normally not a problem, except for
+systems with very small default stack allocations, and applications
+that use multi-line regular expressions (ie, explicitly including ?\n)
+in moderately large files (> 100kB or so).
+
+You may get relief by increasing the amount of stack space allocated
+to your XEmacs process (a system-dependent operation, ask your
+administrator or local experts for help), or by recompiling the regexp
+module regex.c with REGEX_MALLOC defined, relinking, and redumping.
+
+*** At startup I get a warning on stderr about missing charsets:
+
+    Warning: Missing charsets in String to FontSet conversion
+
+You need to specify appropriate charsets for your locale (usually the
+value of the LANG environment variable) in .Xresources.  See
+etc/Emacs.ad for the relevant resources (mostly menubar fonts and
+fontsets).  Do not edit this file, it's purely informative.
+
+If you have no satisfactory fonts for iso-8859-1, XEmacs will crash.
+
+It looks like XFree86 4.x (the usual server on Linux and *BSD) has
+some braindamage where .UTF-8 locales will always generate this
+message, because the XFree86 (font)server doesn't know that UTF-8 will
+use the ISO10646-1 font registry (or a Cmap or something).
+
+If you are not using a .UTF-8 locale and see this warning for a
+character set not listed in the default in Emacs.ad, please let
+xemacs-beta@xemacs.org know about it, so we can add fonts to the
+appropriate fontsets and stifle this warning.  (Unfortunately it's
+buried in Xlib, so we can't easily get rid of it otherwise.)
+
 *** Whenever I try to retrieve a remote file, I have problems.
 
 A typical error: FTP Error: USER request failed; 500 AUTH not understood.
@@ -1189,6 +1246,20 @@ Use the following instead
        Emacs*EmacsFrame.geometry:              81x56--9--1
 
 
+** MacOS/X, Darwin
+*** XEmacs crashes on MacOS within font-lock, or when dealing
+with large compilation buffers, or in other regex applications.
+
+The default stack size under MacOS/X is rather small (512k as opposed
+to Solaris 8M), hosing the regexp code, which uses alloca()
+extensively, overflowing the stack when complex regexps are used.
+Workarounds:
+
+1) Increase your stack size, using `ulimit -s 8192' or a (t)csh
+   equivalent;
+
+2) Recompile regex.c with REGEX_MALLOC defined.
+
 ** AIX
 *** Your Delete key sends a Backspace to the terminal, using an AIXterm.
 
@@ -1391,6 +1462,27 @@ affected virtually all ioctl() calls.
 
 
 ** Linux
+*** XEmacs crashes on exit.
+
+This is known to happen with Lesstif version 0.93.36.  It is
+apparently due to breakage in Lesstif.  There is a patch for Lesstif.
+
+Frank McIngvale <frankm@hiwaay.net> says:
+
+    Ok, 0.93.34 works, and I tracked down the crash to a section
+    marked "experimental" in 0.93.36. Patch attached, "works for me".
+
+diff -u -r lesstif-0.93.36/lib/Xm/ImageCache.c lesstif-0.93.36-mod/lib/Xm/ImageCache.c
+--- lesstif-0.93.36/lib/Xm/ImageCache.c        2002-08-05 14:53:24.000000000 -0500
++++ lesstif-0.93.36-mod/lib/Xm/ImageCache.c    2002-11-11 11:13:12.000000000 -0600
+@@ -1166,5 +1166,4 @@
+       DEBUGOUT(_LtDebug0(__FILE__, NULL, "_LtImageCacheScreenDestroy (XmGetPixmapByDepth) %p\n",
+               s));
+-      (void) _LTHashTableForEachItem(PixmapCache, YowIter, (XtPointer)s);
+ }
+
+
 *** XEmacs crashes on startup, in make-frame.
 
 Typically the Lisp backtrace includes
@@ -1652,7 +1744,7 @@ systems is a C++ lib, which apparently XEmacs cannot cope with.
 
 ** Digital UNIX/OSF/VMS/Ultrix
 *** XEmacs crashes on Digital Unix within font-lock, or when dealing
-with large compilation buffers.
+with large compilation buffers, or in other regex applications.
 
 The default stack size under Digital Unix is rather small (2M as
 opposed to Solaris 8M), hosing the regexp code, which uses alloca()
@@ -1858,6 +1950,14 @@ problem still exists.  Also ask on xemacs-nt@xemacs.org.
 
 
 ** Cygwin
+*** XEmacs fails to start because cygXpm-noX4.dll was not found.
+
+Andy Piper <andy@xemacs.org> sez:
+
+    cygXpm-noX4 is part of the cygwin distribution under libraries or
+    graphics, but is not installed by default. You need to run the
+    cygwin setup again and select this package.
+
 *** Subprocesses do not work.
  
 You do not have "tty" in your CYGWIN environment variable.  This must