9:44 p.m.
Hi folks,
Still trying to get my XEmacs + Gnus setup going. While customizing a
group in XEmacs 21.5, I got the following crash. The stuff about
simplified Chinese is bogus, by the way. I was looking at an email sent
from a Windows user, so it may be some Microsoft brain damage, but was
definitely written in English.
Since I can't yet send email with XEmacs, this is coming to you courtesy
of Evolution. Also, I regret to say that I haven't unlimited
corefilesize, so there is no core file. I'll fix that right away and
see if I can provoke this crash again.
$ xemacs &
checking if Lucida Sans Typewriter-12:hintstyle=3 handles simplified Chinese
Xft font Lucida Sans Typewriter-12:hintstyle=3 doesn't support zh-CN
checking if Nimbus Roman No9 L-12:hintstyle=3 handles simplified Chinese
Xft font Nimbus Roman No9 L-12:hintstyle=3 doesn't support zh-CN
Fatal error: assertion failed, file /home/james/xemacs/xemacs-21.5/src/alloc.c, line 398,
!regex_malloc_disallowed
Fatal error (6).
Your files have been auto-saved.
Use `M-x recover-session' to recover them.
Your version of XEmacs was distributed with a PROBLEMS file that may describe
your crash, and with luck a workaround. Please check it first, but do report
the crash anyway.
Please report this bug by invoking M-x report-emacs-bug, or by selecting
`Send Bug Report' from the Help menu. If that won't work, send ordinary
email to `xemacs-beta(a)xemacs.org'. *MAKE SURE* to include this entire
output from this crash, especially including the Lisp backtrace, as well as
the XEmacs configuration from M-x describe-installation (or equivalently,
the file `Installation' in the top of the build tree).
*Please* try *hard* to obtain a C stack backtrace; without it, we are unlikely
to be able to analyze the problem. Locate the core file produced as a result
of this crash (often called `core' or `core.<process-id>', and located in
the directory in which you started XEmacs or your home directory), and type
gdb /usr/local/test/bin/xemacs core
then type `where' at the debugger prompt. No GDB on your system? You may
have DBX, or XDB, or SDB. (Ask your system administrator if you need help.)
If no core file was produced, enable them (often with `ulimit -c unlimited')
in case of future recurrance of the crash.
Lisp backtrace follows:
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
("(in char-byte conversion)" "[internal]")
# (unwind-protect ...)
# (unwind-protect ...)
re-search-forward("\\b\\(\\(www\\.\\|\\(s?https?\\|ftp\\|file\\|gopher\\|nntp\\|news\\|telnet\\|wais\\|mailto\\|info\\):\\)\\(//[-a-z0-9_.]+:[0-9]*\\)?\\([-a-z0-9_=!?#$ï¼ ~%&*+\\/:;.,]\\|\\w\\)+\\([-a-z0-9_=#$ï¼ ~%&*+\\/]\\|\\w\\)\\)"
nil t)
# bind (inhibit-read-only inhibit-point-motion-hooks case-fold-search alist beg entry
regexp)
# (unwind-protect ...)
# bind (force)
gnus-article-add-buttons()
# (unwind-protect ...)
# bind (--dolist-temp--8834 elem length alist article-goto-body-goes-to-point-min-p
treated-type highlightp val elem type total-parts part-number condition)
gnus-treat-article(nil 1 1)
# (unwind-protect ...)
# bind (display e b type name handle inhibit-read-only handles)
# (unwind-protect ...)
# bind (ssw8827)
# (unwind-protect ...)
# bind (ihandles)
gnus-display-mime()
# bind (gnus-article-buffer buffer-read-only inhibit-read-only)
gnus-article-prepare-display()
# (unwind-protect ...)
# bind (result group gnus-tmp-internal-hook summary-buffer gnus-article)
# (unwind-protect ...)
# bind (header all-headers article)
gnus-article-prepare(2 nil)
# bind (all-header article)
gnus-summary-display-article(2)
# bind (article article-window endp stop circular lines)
gnus-summary-next-page(nil)
# bind (command-debug-status)
call-interactively(gnus-summary-next-page)
(dispatch-event "[internal]")
# (condition-case ... . error)
# (catch top-level ...)
Regards,
--
Jerry James, Assistant Professor Email: Jerry.James(a)usu.edu
Computer Science Dept. Web: http://www.cs.usu.edu/~jerry/
Utah State University
7:10 a.m.
>>>> "Jerry" == Jerry James
<Jerry.James(a)usu.edu> writes:
Jerry> The stuff about simplified Chinese is bogus, by the way.
I'll take a look at that, it's quite possibly Xft breakage. However,
Gnus's I18N misfeatures are legion; it's not possible to rule out
something weird there.
Jerry> Fatal error: assertion failed, file
Jerry> /home/james/xemacs/xemacs-21.5/src/alloc.c, line 398,
Jerry> !regex_malloc_disallowed
ISTR we've seen this a couple times recently (unless those reports
came from you :-). I suspect this is due to Marcus's work in the
allocation code. Any thoughts, Marcus?
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
3:37 p.m.
On Tue, Mar 14 2006, Stephen J. Turnbull wrote:
However, Gnus's I18N misfeatures are legion;
Care to explain? Or give us some URLs or MIDs?
Bye, Reiner.
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
5:09 p.m.
>>>> "Reiner" == Reiner Steib
<reinersteib+gmane(a)imap.cc> writes:
Reiner> On Tue, Mar 14 2006, Stephen J. Turnbull wrote:
> However, Gnus's I18N misfeatures are legion;
Reiner> Care to explain? Or give us some URLs or MIDs?
Here are the reasons that bit me this week:
1. Something isn't checking for the coding-system `gnus-decoded',
which gets propagated as a buffer-local value (typically the
*Article* buffer) of some coding system variable used by nnmail,
thus making the error essentially permanent until you kill the
buffer.
2. In Japanese mail, ASCII gets RFC2231-encoded under at least some
circumstances in references to local files in external bodies.
(All the time for me, but what usually happens is I do
gnus-mime-save-part-and-strip, then change the name from an
ISO-2022-JP-encoded abomination -- Gnus didn't seem to pay
attention to `file-name-coding-system' last I checked -- to an
ASCII name for safety. So Gnus may be "remembering" that this
used to be a name that requires RFC2231, and then does it to ASCII
even though it's unnecessary and stupid.)
3. Every time you edit a mail, the RFC2231-encoded parameters get
re-encoded when you save. This is particularly annoying when
somebody sends you a 15-attachment mail.
4. The code for viewing MIME parts doesn't seem to grok RFC2231;
clicking on an encoded external body gives a "I can't find any
file with a name that seems to be RFC2231-encoded" error.
5. There's no proper way to set the charset parameter when editing a
message.
6. Address headers don't get RFC2047-encoded in Japanese mail. (This
is a multiple regression, sometimes it works, sometimes it don't,
lather, rinse, repeat.)
7. Gnus doesn't seem to provide a useful way to "wash" mail with a
broken Content-Type header. I haven't actually checked that in a
couple years -- I've had a helper function to do that since 1998,
so it wasn't really worth searching. And I don't recall exactly
what my definition of "useful wash" was, I seem to recall there
was a "view as charset" option but that didn't do what I wanted.
Gnus version 5.10.7, XEmacs package 1.89.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
7:27 a.m.
>>>>"JJ" == Jerry James
<Jerry.James(a)usu.edu> writes:
JJ> Fatal error: assertion failed, file
JJ> /home/james/xemacs/xemacs-21.5/src/alloc.c, line 398,
JJ> !regex_malloc_disallowed
If you've enabled the new garbage collector, this seems to be a
problem I've introduced. I've received another bug report about
regex_malloc_disallowed, and got bitten by this bug myself once. If
you have a --disable-newgc build, I am more than happy because then
this bug isn't a NEWGC problem, but I doubt it. Anyway, I am going to
look into this the next days.
--
Marcus
4:23 a.m.
Marcus Crestani <crestani(a)informatik.uni-tuebingen.de> wrote:
>>>>>"JJ" == Jerry James
<Jerry.James(a)usu.edu> writes:
JJ> Fatal error: assertion failed, file
JJ> /home/james/xemacs/xemacs-21.5/src/alloc.c, line 398,
JJ> !regex_malloc_disallowed
If you've enabled the new garbage collector, this seems to be a
problem I've introduced. I've received another bug report about
regex_malloc_disallowed, and got bitten by this bug myself once. If
you have a --disable-newgc build, I am more than happy because then
this bug isn't a NEWGC problem, but I doubt it. Anyway, I am going to
look into this the next days.
Yes, I have newgc turned on. I am also happy to report that this bug is
very easy to trigger with Gnus. So easy to trigger, in fact, that I've
given up using Gnus with XEmacs 21.5 for the time being. But I'm also
happy to report that Gnus + XEmacs 21.4 is working quite well for me.
Hurrah!
--
Jerry James, Assistant Professor james(a)xemacs.org
Computer Science Department http://www.cs.usu.edu/~jerry/
Utah State University
7:41 a.m.
Jerry James <james(a)xemacs.org> writes:
Marcus Crestani <crestani(a)informatik.uni-tuebingen.de> wrote:
>>>>>>"JJ" == Jerry James <Jerry.James(a)usu.edu> writes:
> JJ> Fatal error: assertion failed, file
> JJ> /home/james/xemacs/xemacs-21.5/src/alloc.c, line 398,
> JJ> !regex_malloc_disallowed
>
> If you've enabled the new garbage collector, this seems to be a
> problem I've introduced. I've received another bug report about
> regex_malloc_disallowed, and got bitten by this bug myself once. If
> you have a --disable-newgc build, I am more than happy because then
> this bug isn't a NEWGC problem, but I doubt it. Anyway, I am going to
> look into this the next days.
Yes, I have newgc turned on. I am also happy to report that this bug is
very easy to trigger with Gnus. So easy to trigger, in fact, that I've
given up using Gnus with XEmacs 21.5 for the time being.
This, presumably, depends on your configuration. I have almost no
problems with Gnus and XEmacs 21.5 (full debug and error checking)
running, so it isn't quite that simple, thankfully.
NEWGC does run very well for me, and the asynchronous finalization code
means that my previous fix to the image GC code is no longer need, which
is lovely.
I have run into one issue, thus far, which is that a long running XEmacs
worked slowly up to 608MB of allocated memory before it stopped being
able to fork and I restarted it.[1]
On that topic, what is the best way to track down a memory leak with the
NEWGC code? Is there anything specific that I can look at to help work
out what the leak is and why it is happening?
Daniel
Footnotes:
[1] Foolishly, I didn't actually bother to grab a core or any memory
use information, so I am currently working back up toward that.
--
Digital Infrastructure Solutions -- making IT simple, stable and secure
Phone: 0401 155 707 email: contact(a)digital-infrastructure.com.au
10:24 a.m.
>>>>"DP" == Daniel Pittman
<daniel(a)rimspace.net> writes:
> Yes, I have newgc turned on. I am also happy to report that this bug is
> very easy to trigger with Gnus. So easy to trigger, in fact, that I've
> given up using Gnus with XEmacs 21.5 for the time being.
DP> This, presumably, depends on your configuration. I have almost no
DP> problems with Gnus and XEmacs 21.5 (full debug and error checking)
DP> running, so it isn't quite that simple, thankfully.
Same here. I hit this bug once and am failing since then to reproduce
it.
Jerry, can you please post your Installation file?
DP> NEWGC does run very well for me, and the asynchronous finalization code
DP> means that my previous fix to the image GC code is no longer need, which
DP> is lovely.
Do you mean this?
Subject: [PATCH] [RECOMMEND 21.4] Stopping timeouts during GC causes lossage
on all GUI platforms (X11, GTK and Win32)
DP> I have run into one issue, thus far, which is that a long running XEmacs
DP> worked slowly up to 608MB of allocated memory before it stopped being
DP> able to fork and I restarted it.[1]
DP> On that topic, what is the best way to track down a memory leak with the
DP> NEWGC code? Is there anything specific that I can look at to help work
DP> out what the leak is and why it is happening?
The only thing is to keep an eye on show-object-memory-usage-stats and
show-mc-alloc-memory-usage and see which objects escape. It might
also be a fragmentation problem of the allocator.
Valgrind might be useful, but there are issues with NEWGC's write
barrier: The virtual dirty bit write barrier provokes SEGFAULTs on
purpose to keep track of object modifications. Valgrind reports all
of these SEGFAULTs, which makes it is practically useless. But
valgrind is able to ignore certain bugs, defined by a set of rules,
called supressions. Maybe this way valgrind can be tweaked to work
with the write barrier. Before I start on this: Is somebody here
familiar with valgrind supressions?
--
Marcus
11:55 p.m.
Marcus Crestani <crestani(a)informatik.uni-tuebingen.de> writes:
>>>>>"DP" == Daniel Pittman
<daniel(a)rimspace.net> writes:
[...]
DP> NEWGC does run very well for me, and the asynchronous
finalization
DP> code means that my previous fix to the image GC code is no longer
DP> need, which is lovely.
Do you mean this?
Subject: [PATCH] [RECOMMEND 21.4] Stopping timeouts during GC causes lossage
on all GUI platforms (X11, GTK and Win32)
Yes. The timeout is related to animated image glyphs, and the solution
was to introduce an asynchronous finalization for the timeout object.
With your code doing that generically the problem (corruption or an
assert due to a synchronous Lisp object free during a GC run) has gone
away, so my specific fix is no longer necessary.
DP> I have run into one issue, thus far, which is that a long
running
DP> XEmacs worked slowly up to 608MB of allocated memory before it
DP> stopped being able to fork and I restarted it.[1]
DP> On that topic, what is the best way to track down a memory leak
DP> with the NEWGC code? Is there anything specific that I can look
DP> at to help work out what the leak is and why it is happening?
The only thing is to keep an eye on show-object-memory-usage-stats and
show-mc-alloc-memory-usage and see which objects escape. It might
also be a fragmentation problem of the allocator.
No problem. I will look to getting a core, memory stats, etc for you.
It looks like reproducing the issue isn't to be a problem; XEmacs has
gained around 96MB VSS over the last day or so, so I should hit the
bloaty problem later.
Valgrind might be useful, but there are issues with NEWGC's
write
barrier: The virtual dirty bit write barrier provokes SEGFAULTs on
purpose to keep track of object modifications. Valgrind reports all
of these SEGFAULTs, which makes it is practically useless.
I might take a look at that, especially if someone else provides the
solution to suppressing the reports; I have never worked with valgrind
before.
I can't promise too much work on debugging this, though, as my time is
currently very over-committed to work. :?
Daniel
--
Digital Infrastructure Solutions -- making IT simple, stable and secure
Phone: 0401 155 707 email: contact(a)digital-infrastructure.com.au
5:09 p.m.
>>>>"DP" == Daniel Pittman
<daniel(a)rimspace.net> writes:
DP> With your code doing that generically the
problem (corruption or
DP> an assert due to a synchronous Lisp object free during a GC run)
DP> has gone away, so my specific fix is no longer necessary.
Good to hear.
DP> I might take a look at that, especially if someone else provides
DP> the solution to suppressing the reports; I have never worked with
DP> valgrind before.
I found this in the valgrind manual:
--gen-suppressions=no|yes print suppressions for errors detected [no]
I'll see if this does the magic for us somewhen next week, if you get
to it earlier be my guest and go ahead ;-).
--
Marcus
12:53 p.m.
New subject: Valgrind with NEWGC (was: 21.5 crash in Gnus)
>>>>"DP" == Daniel Pittman
<daniel(a)rimspace.net> writes:
DP> I might take a look at that, especially
if someone else provides
DP> the solution to suppressing the reports; I have never worked with
DP> valgrind before.
>>>>"MC" == Marcus Crestani
<crestani(a)informatik.uni-tuebingen.de> writes:
MC> I found this in the
valgrind manual:
MC> --gen-suppressions=no|yes print suppressions for errors detected [no]
MC> I'll see if this does the magic for us somewhen next week, if you get
MC> to it earlier be my guest and go ahead ;-).
Together with the excellent support of the valgrind people I was able
to figure out how to use valgrind with the virtual dirty bit write
barrier of NEWGC.
Run valgrind with the option `--vex-iropt-precise-memory-exns=yes' to
enable the magic that allows valgrind to work with the write barrier's
signal handlers. By default Valgrind optimises the code it generates
in such a way that the simulated registers are not always up to date,
so when the exception happens, in effect some of the most recent
changes to the simulated registers are
lost. `--vex-iropt-precise-memory-exns=yes' disables this optimisation
at the cost of some performance overhead.
--
Marcus
11:59 a.m.
By coincidence today I also managed to crash twice in gnus with 21.5. As far
as I can tell they're unrelated to Jerry's problems.
This is running 21.5 HEAD-as-of-a-week-ago on a Fedora Core 3 box. A build of
HEAD from a few weeks prior to that doesn't exhibit this problem so I wonder
if one of the newgc changes escaped a #ifdef?
Malcolm
---------------------------------------------------------------------------
Crash 1:
(gdb) run -geometry 85x65
Starting program: /export/home/malcolmp/builds/xemacs/objdirs/occur-debug/src/xemacs
-geometry 85x65
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0xb7fb9000
[Thread debugging using libthread_db enabled]
[New Thread -1208513920 (LWP 17797)]
Detaching after fork from child process 17800.
Detaching after fork from child process 17802.
Detaching after fork from child process 17803.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208513920 (LWP 17797)]
0x08141ea1 in mark_object_maybe_checking_free_1 (obj=185922324, allow_free=0,
level=2670, pos=1)
at /home/malcolmp/builds/xemacs/sandboxen/21.5-micro-patches/src/gc.c:974
974 KKCC_DO_CHECK_FREE (obj, allow_free);
(gdb) where
#0 0x08141ea1 in mark_object_maybe_checking_free_1 (obj=185922324,
allow_free=0, level=2670, pos=1)
at /home/malcolmp/builds/xemacs/sandboxen/21.5-micro-patches/src/gc.c:974
#1 0x0814210c in kkcc_marking (unused_cnt=0)
at /home/malcolmp/builds/xemacs/sandboxen/21.5-micro-patches/src/gc.c:1176
#2 0x08142cf5 in garbage_collect_1 ()
at /home/malcolmp/builds/xemacs/sandboxen/21.5-micro-patches/src/gc.c:2057
#3 0x080d9810 in Feval (form=178825428)
at /home/malcolmp/builds/xemacs/sandboxen/21.5-micro-patches/src/eval.c:3568#4
0x08192ca0 in readevalloop (readcharfun=186149728, sourcename=184845492,
evalfun=0x80d94bc <Feval>, printflag=0)
at /home/malcolmp/builds/xemacs/sandboxen/21.5-micro-patches/src/lread.c:1466
#5 0x08191143 in Fload_internal (file=184845492, noerror=137428956,
nomessage=137374764, nosuffix=137428956, codesys=137409492,
used_codesys=137428956)
at /home/malcolmp/builds/xemacs/sandboxen/21.5-micro-patches/src/lread.c:767#6
0x080dae69 in Ffuncall (nargs=6, args=0xbfab6a84)
at /home/malcolmp/builds/xemacs/sandboxen/21.5-micro-patches/src/eval.c:3893#7
0x0809ceb8 in execute_optimized_program (
(gdb) print *((struct lrecord_header *) obj)
$13 = {type = 212, mark = 0, c_readonly = 0, lisp_readonly = 0, uid = 67795}
---------------------------------------------------------------------------
Crash 2:
Fatal error: assertion failed, file
/home/malcolmp/builds/xemacs/sandboxen/21.5-micro-patches/src/print.c, line 1522, ABORT()
Program received signal SIGABRT, Aborted.
[Switching to Thread -1208448384 (LWP 27578)]
0xb7fc9402 in __kernel_vsyscall ()
(gdb) where
#0 0xb7fc9402 in __kernel_vsyscall ()
#1 0x006327d5 in raise () from /lib/tls/libc.so.6
#2 0x00634149 in abort () from /lib/tls/libc.so.6
#3 0x080d3450 in really_abort ()
at /home/malcolmp/builds/xemacs/sandboxen/21.5-micro-patches/src/emacs.c:4692
#4 0x080d2163 in assert_failed (
file=0x82a95b4
"/home/malcolmp/builds/xemacs/sandboxen/21.5-micro-patches/src/print.c",
line=1522, expr=0x82a9752 "ABORT()")
at /home/malcolmp/builds/xemacs/sandboxen/21.5-micro-patches/src/emacs.c:3985
#5 0x081b88cd in printing_major_badness (printcharfun=154501472,
badness_string=0x82a9815 "illegal lrecord type", type=232, val=0xa1b3560,
badness=BADNESS_POINTER_OBJECT)
at /home/malcolmp/builds/xemacs/sandboxen/21.5-micro-patches/src/print.c:1522
#6 0x081b8dc6 in print_internal (obj=169555296, printcharfun=154501472,
escapeflag=1)
at /home/malcolmp/builds/xemacs/sandboxen/21.5-micro-patches/src/print.c:1711
#7 0x081b698f in print_error_message (error_object=169161820,
stream=154501472)
at /home/malcolmp/builds/xemacs/sandboxen/21.5-micro-patches/src/print.c:101---Type
<return> to continue, or q <return> to quit---q
Quit
(gdb) up
#1 0x006327d5 in raise () from /lib/tls/libc.so.6
(gdb) up
#2 0x00634149 in abort () from /lib/tls/libc.so.6
(gdb) up
#3 0x080d3450 in really_abort ()
at /home/malcolmp/builds/xemacs/sandboxen/21.5-micro-patches/src/emacs.c:4692
4692 abort ();
(gdb) up
#4 0x080d2163 in assert_failed (
file=0x82a95b4
"/home/malcolmp/builds/xemacs/sandboxen/21.5-micro-patches/src/print.c",
line=1522, expr=0x82a9752 "ABORT()")
at /home/malcolmp/builds/xemacs/sandboxen/21.5-micro-patches/src/emacs.c:3985
3985 really_abort ();
(gdb) up
#5 0x081b88cd in printing_major_badness (printcharfun=154501472,
badness_string=0x82a9815 "illegal lrecord type", type=232, val=0xa1b3560,
badness=BADNESS_POINTER_OBJECT)
at /home/malcolmp/builds/xemacs/sandboxen/21.5-micro-patches/src/print.c:1522
1522 ABORT ();
(gdb) up
#6 0x081b8dc6 in print_internal (obj=169555296, printcharfun=154501472,
escapeflag=1)
at /home/malcolmp/builds/xemacs/sandboxen/21.5-micro-patches/src/print.c:1711
1711 printing_major_badness (printcharfun, "illegal lrecord
type",
(gdb) print *lheader
$1 = {type = 232, mark = 1, c_readonly = 0, lisp_readonly = 0, uid = 67797}
(gdb) print lrecord_type_count
$2 = 69
(gdb)
---------------------------------------------------------------------------
Contents of 'Installation'
uname -a: Linux malcolmp.sw.oz.au 2.6.12-1.1381_FC3 #1 Fri Oct 21 03:46:55 EDT 2005 i686
i686 i386 GNU/Linux
../../sandboxen/21.5-micro-patches/configure '--prefix=/home/malcolmp/prefix'
'--enable-mule' '--with-system-malloc'
XEmacs 21.5-b25 "eggplant" (+CVS-20060227) configured for `i686-pc-linux'.
Compilation Environment and Installation Defaults:
Source code location:
/home/malcolmp/builds/xemacs/sandboxen/21.5-micro-patches
Installation prefix: /home/malcolmp/prefix
Operating system description file: `s/linux.h'
Machine description file: `m/intel386.h'
Compiler version: gcc (GCC) 3.4.4 20050721 (Red Hat 3.4.4-2)
- GCC specs file: /usr/lib/gcc/i386-redhat-linux/3.4.4/specs
- Compiler command: gcc -Wall -Wno-switch -Wundef -Wsign-compare
-Wno-char-subscripts -Wpacked -Wunused-parameter -g
libc version: glibc-2.3.6-0.fc3.1
Relocating allocator for buffers: no
GNU version of malloc: no
- User chose not to use GNU allocators.
Window System:
Compiling in support for the X window system:
- X Windows headers location: /usr/X11R6/include
- X Windows libraries location: /usr/X11R6/lib
- Handling WM_COMMAND properly.
Compiling in support for the Athena widget set:
- Athena headers location: X11/Xaw
- Athena library to link: Xaw
Using Lucid menubars.
Using Lucid scrollbars.
Using Athena dialog boxes.
Using Athena native widgets.
TTY:
Compiling in support for ncurses.
Compiling in support for GPM (General Purpose Mouse).
Images:
Compiling in support for GIF images (builtin).
Compiling in support for XPM images.
WARNING: -----------------------------------------------------------
WARNING: Compiling without PNG image support.
WARNING: You should strongly consider installing the PNG libraries.
WARNING: Otherwise certain images and glyphs may not display.
WARNING: (a copy may be found in ftp://ftp.xemacs.org/pub/xemacs/aux)
WARNING: -----------------------------------------------------------
Compiling in support for JPEG images.
Compiling in support for TIFF images.
Compiling in support for X-Face message headers.
Sound:
Compiling in support for sound (native).
Databases:
Compiling in support for Berkeley database.
Compiling in support for LDAP.
Internationalization:
Compiling in support for Mule (multi-lingual Emacs).
Compiling in support for XIM (X11R5+ I18N input method).
- Using raw Xlib to provide XIM support.
Mail:
Compiling in support for "file" mail spool file locking method.
Other Features:
Inhibiting IPv6 canonicalization at startup.
Compiling in support for dynamic shared object modules.
Using the new GC mark algorithms (KKCC).
WARNING: ---------------------------------------------------------
WARNING: The new algorithms are experimental. They are enabled by
WARNING: default for this release. Use `--disable-kkcc' to
WARNING: turn it off.
WARNING: ---------------------------------------------------------
Using the new portable dumper.
Dumping into executable.
Compiling in support for extra debugging code.
Compiling in support for runtime error checking.
WARNING: ---------------------------------------------------------
WARNING: XEmacs will run noticeably more slowly as a result.
WARNING: Error checking is on by default for XEmacs beta releases.
WARNING: ---------------------------------------------------------
--
Malcolm Purvis <malcolmp(a)xemacs.org>
10:02 a.m.
>>>>"MP" == Malcolm Purvis
<malcolmp(a)xemacs.org> writes:
MP> HEAD from a few weeks prior to that
doesn't exhibit this problem
MP> so I wonder if one of the newgc changes escaped a #ifdef?
Thanks for the reports, Malcolm.
I put it on my list (sometimes I really wish we had a bug tracking
system).
--
Marcus
6603
days inactive
6612
days old
12 comments
7 participants
participants (7)
-
Daniel Pittman -
Jerry James -
Jerry James -
Malcolm Purvis -
Marcus Crestani -
Reiner Steib -
Stephen J. Turnbull