11:30 p.m.
Hi,
I have started to get errors like the line below the last week or so:
"*** glibc detected *** malloc(): memory corruption: 0x088cc680 ***"
Could this have anything to do with the new GC? Would a backtrace be
helpful?
----------------------------------------------------------------------
uname -a: Linux spencer 2.6.15-gentoo-r1 #1 SMP PREEMPT Mon Jan 23 00:30:12 CET 2006 i686
Intel(R) Pentium(R) M processor 1300MHz GenuineIntel GNU/Linux
./configure '--prefix=/src/xemacs' '--enable-mule'
'--with-package-path=/src/xemacs/xemacs-packages:/src/xemacs/mule-packages:/src/xemacs/site-packages'
'--enable-sound=esd' '--enable-database=no' '--enable-kkcc'
'--enable-mc-alloc' '--enable-widgets=athena'
'--enable-dialogs=athena' '--with-athena=3d' '--with-xim=xlib'
'--with-xfs=all'
XEmacs 21.5-b25 "eggplant" (+CVS-20060313) configured for `i686-pc-linux'.
Compilation Environment and Installation Defaults:
Source code location: /src/xemacs/working
Installation prefix: /src/xemacs
Operating system description file: `s/linux.h'
Machine description file: `m/intel386.h'
Compiler version: gcc (GCC) 3.4.5 (Gentoo 3.4.5, ssp-3.4.5-1.0,
pie-8.7.9)
- GCC specs file: /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/specs
- Compiler command: gcc -Wall -Wno-switch -Wundef -Wsign-compare
-Wno-char-subscripts -Wpacked -Wunused-parameter -g
libc version: 2.3.5
Relocating allocator for buffers: no
GNU version of malloc: yes
- Using Doug Lea's new malloc from the GNU C Library.
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/Xaw3d
- Athena library to link: Xaw3d
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.
Compiling in support for PNG images.
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).
Compiling in support for ESD (Enlightened Sound Daemon).
Databases:
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: ---------------------------------------------------------
----------------------------------------------------------------------
Yours
--
%% Mats
11:47 p.m.
Mats Lidell <matsl(a)xemacs.org> writes:
Hi,
I have started to get errors like the line below the last week or so:
"*** glibc detected *** malloc(): memory corruption: 0x088cc680 ***"
Could this have anything to do with the new GC? Would a backtrace be
helpful?
Mats, I'm not sure, but it looks as if you have note enabled the new
incremental garbage collector itself.
Try again with
--enable-newgc
Other than that your configuration below looks good for providing
useful call stack information.
Good Luck,
Adrian
----------------------------------------------------------------------
uname -a: Linux spencer 2.6.15-gentoo-r1 #1 SMP PREEMPT Mon Jan 23 00:30:12 CET 2006 i686
Intel(R) Pentium(R) M processor 1300MHz GenuineIntel GNU/Linux
./configure '--prefix=/src/xemacs' '--enable-mule'
'--with-package-path=/src/xemacs/xemacs-packages:/src/xemacs/mule-packages:/src/xemacs/site-packages'
'--enable-sound=esd' '--enable-database=no' '--enable-kkcc'
'--enable-mc-alloc' '--enable-widgets=athena'
'--enable-dialogs=athena' '--with-athena=3d' '--with-xim=xlib'
'--with-xfs=all'
XEmacs 21.5-b25 "eggplant" (+CVS-20060313) configured for `i686-pc-linux'.
Compilation Environment and Installation Defaults:
Source code location: /src/xemacs/working
Installation prefix: /src/xemacs
Operating system description file: `s/linux.h'
Machine description file: `m/intel386.h'
Compiler version: gcc (GCC) 3.4.5 (Gentoo 3.4.5, ssp-3.4.5-1.0,
pie-8.7.9)
- GCC specs file: /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/specs
- Compiler command: gcc -Wall -Wno-switch -Wundef -Wsign-compare
-Wno-char-subscripts -Wpacked -Wunused-parameter -g
libc version: 2.3.5
Relocating allocator for buffers: no
GNU version of malloc: yes
- Using Doug Lea's new malloc from the GNU C Library.
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/Xaw3d
- Athena library to link: Xaw3d
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.
Compiling in support for PNG images.
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).
Compiling in support for ESD (Enlightened Sound Daemon).
Databases:
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: ---------------------------------------------------------
----------------------------------------------------------------------
Yours
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
7:30 a.m.
Adrian Aichner writes:
Mats, I'm not sure, but it looks as if you have note enabled the
new
incremental garbage collector itself.
OK. I though that ">> Using the new GC mark algorithms (KKCC)." was just
that but then
again it might just be the "new GC mark algorithms" which probably is something
completely different.
Try again with
--enable-newgc
Thanks. I might do that but then, if I'm not using the new GC, the problem is more
alarming because it then seems like something old is broken.
Other than that your configuration below looks good for providing
useful call stack information.
Let me try again. I have a stack trace. I just want to know whether it can be useful
when it comes to these "Memory corruption errors".
Yours
--
%% Mats
8:30 a.m.
>>>> "Mats" == Mats Lidell
<matsl(a)xemacs.org> writes:
Mats> Adrian Aichner writes:
> Mats, I'm not sure, but it looks as if you have note enabled
> the new incremental garbage collector itself.
That's correct. It's not yet enabled by default.
Mats> OK. I though that "Using the new GC mark algorithms (KKCC)."
Mats> was just that but then again it might just be the "new GC
Mats> mark algorithms" which probably is something completely
Mats> different.
That's right. There are in fact four fairly well-defined subtasks:
1) Regularizing the memory layouts and providing them with
descriptions that various subsystems can interpret. This doesn't
really have its own option or #ifdef macro AIUI. This required
for the MC_ALLOC and NEWGC tasks.
2) Changing the mark algorithm to be more modular, to allow
allocation and GC algorithms to be changed more easily. This is
the KKCC part.
3) Changing and generalizing the Lisp allocator, to cooperate with
various mark and GC algorithms and regularize internal memory
allocation. Although there have been some growing pains, this
should eventually help us capture almost all XEmacs internal
allocation in the memory usage statistics. (We'll still face the
issue that X11 and various image and font libraries do their own
internal allocation, so XEmacs-reported memory size will always be
substantially smaller than VSIZE in ps.) This is denoted MC_ALLOC.
4) Changing the GC algorithm itself. This was called NEWGC, but in
fact technically it's very hard to disentangle from the allocator,
so Marcus put this under control of MC_ALLOC in the source code.
Thus now there are changes that don't depend on any of the switches,
mark algorithm changes that depend on --with-kkcc (on by default) and
allocation and gc algorithm changes that depend on --with-mc-alloc.
Not as clean as you might like, but there are limits to how much
backward compatibility you can preserve with this kind of refactoring.
Mats> Thanks. I might do that but then, if I'm not using the new
Mats> GC, the problem is more alarming because it then seems like
Mats> something old is broken.
This is quite likely, since the whole effort is a refactoring.
Mats> Let me try again. I have a stack trace. I just want to know
Mats> whether it can be useful when it comes to these "Memory
Mats> corruption errors".
I believe there are debugging techniques that GCC can enable without
much external support, but I don't know much about them. You could
also run with valgrind, which is known to be very effective for this
kind of debugging.
All of the above should be considered interim discussion until Marcus
has time to weigh in with accurate information, but that should give
you a feel for what's going on.
HTH!
--
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.
10 a.m.
>>>>"sjt" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
sjt> That's right. There are in fact four
fairly well-defined subtasks:
Nice summary, thanks!
sjt> 1) Regularizing the memory layouts and providing them with
sjt> descriptions that various subsystems can interpret. This doesn't
sjt> really have its own option or #ifdef macro AIUI. This required
sjt> for the MC_ALLOC and NEWGC tasks.
And it is required for the portable dumper. It introduced the
descriptions.
sjt> 2) Changing the mark algorithm to be more modular, to allow
sjt> allocation and GC algorithms to be changed more easily. This is
sjt> the KKCC part.
The mark algorithm uses an explicit stack that keeps track of the
current progress of traversal, instead of the recursion that
mark_object uses.
sjt> 3) Changing and generalizing the Lisp allocator, to cooperate with
sjt> various mark and GC algorithms and regularize internal memory
sjt> allocation. Although there have been some growing pains, this
sjt> should eventually help us capture almost all XEmacs internal
sjt> allocation in the memory usage statistics. (We'll still face the
sjt> issue that X11 and various image and font libraries do their own
sjt> internal allocation, so XEmacs-reported memory size will always be
sjt> substantially smaller than VSIZE in ps.) This is denoted MC_ALLOC.
I wouldn't stress the memory usage statistics, which is a by-product
IMO. The real benefit, as Stephen mentions correctly, is the
regularized internal memory allocation.
sjt> 4) Changing the GC algorithm itself. This was called NEWGC, but in
sjt> fact technically it's very hard to disentangle from the allocator,
sjt> so Marcus put this under control of MC_ALLOC in the source code.
Stephen mixed this up: I removed MC_ALLOC and put it under control of
NEWGC.
sjt> Thus now there are changes that don't depend on any of the switches,
sjt> mark algorithm changes that depend on --with-kkcc (on by default) and
sjt> allocation and gc algorithm changes that depend on --with-mc-alloc.
To enable the new allocator and the new incremental garbage collector,
you have to use --enable-newgc. The configuration option
--enable-mc-alloc is gone.
sjt> Not as clean as you might like, but there are limits to how much
sjt> backward compatibility you can preserve with this kind of refactoring.
The new allocator has certain features like allocation of Lisp arrays
that the old allocator doesn't have.
sjt> I believe there are debugging techniques that GCC can enable without
sjt> much external support, but I don't know much about them. You could
sjt> also run with valgrind, which is known to be very effective for this
sjt> kind of debugging.
I recommend to use valgrind, it should find this bug. Then, you can
attach a debugger and get a backtrace.
--
Marcus
8:34 a.m.
Adrian Aichner wrote:
Mats Lidell <matsl(a)xemacs.org> writes:
Mats, I'm not sure, but it looks as if you have note enabled the new
incremental garbage collector itself.
Try again with
--enable-newgc
Using the newgc made the memory problem go way. That made my day but someone should
maybe look out for this and why it occured in the first place. Maybe all 21.5 users are
using the new newgc, ;-), or have not synced with CVS lately, :-(.
Yours
--
%% Mats
5:12 p.m.
>>>>"ML" == Mats Lidell <matsl(a)xemacs.org>
writes:
ML> Adrian Aichner wrote:
> Mats Lidell <matsl(a)xemacs.org> writes:
>
> Mats, I'm not sure, but it looks as if you have note enabled the new
> incremental garbage collector itself.
>
> Try again with
> --enable-newgc
ML> Using the newgc made the memory problem go way. That made my day
ML> but someone should maybe look out for this and why it occured in
ML> the first place. Maybe all 21.5 users are using the new newgc,
ML> ;-), or have not synced with CVS lately, :-(.
It would be really helpful if you could run valgrind on your broken
build (the one without NEWGC).
Something like
valgrind --db-attach=gdb src/xemacs
or
valgrind --gdb-attach=yes src/xemacs
should do the trick (depends on your valgrind version).
When valgrind complains about the memory corruption, please attach the
debugger and post the backtrace.
Thanks,
--
Marcus
1:28 p.m.
>>>> Marcus wrote:
Marcus> It would be really helpful if you could run valgrind on your broken
Marcus> build (the one without NEWGC).
OK. Doing make in ".../mule-packages/latin-unit" is one way of getting
the problem. It is very reliable also. Happens all the time which
makes the analysis a bit easier.
I only created the backtrace for the first memory problem. So here
goes (all output from the session inluded below) ...
----------------------------------------------------------------------
==4018== Memcheck, a memory error detector for x86-linux.
==4018== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==4018== Using valgrind-2.4.0, a program supervision framework for x86-linux.
==4018== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==4018== For more details, rerun with: -v
==4018==
Loading /src/xemacs/packages/package-compile.el...
Loading /src/xemacs/lib/xemacs-21.5-b25/lisp/auto-autoloads.elc...
Requiring /src/xemacs/lib/xemacs-21.5-b25/lisp/bytecomp.elc...
Requiring /src/xemacs/lib/xemacs-21.5-b25/lisp/byte-optimize.elc...
Loading /src/xemacs/packages/xemacs-packages/dired/auto-autoloads.elc...
Loading /src/xemacs/packages/xemacs-packages/fsf-compat/auto-autoloads.elc...
Loading /src/xemacs/packages/mule-packages/leim/auto-autoloads.elc...
Loading /src/xemacs/packages/mule-packages/mule-ucs/lisp/auto-autoloads.elc...
Loading /src/xemacs/packages/mule-packages/latin-euro-standards/auto-autoloads.elc...
Loading /src/xemacs/packages/mule-packages/mule-base/auto-autoloads.elc...
Loading /src/xemacs/lib/xemacs-21.5-b25/lisp/cl-macs.elc...
Loading /src/xemacs/packages/mule-packages/latin-unity/latin-unity-vars.el...
Requiring
/src/xemacs/packages/mule-packages/latin-euro-standards/latin-euro-standards.elc...
Requiring
/src/xemacs/packages/mule-packages/latin-euro-standards/latin-euro-latin7.elc...==4018==
Invalid write of size 1
==4018== at 0x1B905FCC: memcpy (in /usr/lib/valgrind/vgpreload_memcheck.so)
==4018== by 0x80C7C45: Dynarr_realloc (dynarr.c:137)
==4018== by 0x80C7D49: Dynarr_resize (dynarr.c:211)
==4018== by 0x823CFB4: recalculate_unicode_precedence (unicode.c:1097)
==4018== by 0x81B1D73: make_charset (mule-charset.c:272)
==4018== by 0x81B28DD: Fmake_charset (mule-charset.c:613)
==4018== by 0x80DD703: Ffuncall (eval.c:3893)
==4018== by 0x809E5A0: execute_optimized_program (bytecode.c:862)
==4018== by 0x80A3611: Fbyte_code (bytecode.c:2620)
==4018== by 0x80DC55E: Feval (eval.c:3646)
==4018== by 0x819F75D: readevalloop (lread.c:1466)
==4018== by 0x819D9FF: Fload_internal (lread.c:767)
==4018== Address 0x1BF68D67 is 1 bytes before a block of size 1200 alloc'd
==4018== at 0x1B90524A: calloc (in /usr/lib/valgrind/vgpreload_memcheck.so)
==4018== by 0x808B23B: xcalloc (alloc.c:382)
==4018== by 0x808B27C: xmalloc_and_zero (alloc.c:391)
==4018== by 0x80CFC0B: resize_hash_table (elhash.c:1069)
==4018== by 0x80CFED2: enlarge_hash_table (elhash.c:1126)
==4018== by 0x80D01CC: Fputhash (elhash.c:1199)
==4018== by 0x80C3006: make_directory_hash_table (dired.c:792)
==4018== by 0x819E52B: locate_file_refresh_hashing (lread.c:899)
==4018== by 0x819E595: locate_file_find_directory_hash_table (lread.c:914)
==4018== by 0x819F0DB: locate_file (lread.c:1285)
==4018== by 0x819E4FA: Flocate_file (lread.c:889)
==4018== by 0x80DD73C: Ffuncall (eval.c:3893)
==4018==
==4018== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- starting debugger
==4018== starting debugger with cmd: /usr/bin/gdb -nw /proc/4020/fd/1015 4020
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library
"/lib/libthread_db.so.1".
Attaching to program: /proc/4020/fd/1015, process 4020
`system-supplied DSO at 0xffffe000' has disappeared; keeping its symbols.
Reading symbols from /usr/lib/valgrind/vg_inject.so...done.
Loaded symbols for /usr/lib/valgrind/vg_inject.so
Reading symbols from /usr/lib/valgrind/vgpreload_memcheck.so...done.
Loaded symbols for /usr/lib/valgrind/vgpreload_memcheck.so
Reading symbols from /usr/lib/libXaw3d.so.8...done.
Loaded symbols for /usr/lib/libXaw3d.so.8
Reading symbols from /usr/lib/libtiff.so.3...done.
Loaded symbols for /usr/lib/libtiff.so.3
Reading symbols from /usr/lib/libpng.so.3...done.
Loaded symbols for /usr/lib/libpng.so.3
Reading symbols from /usr/lib/libjpeg.so.62...done.
Loaded symbols for /usr/lib/libjpeg.so.62
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /usr/lib/libXpm.so.4...done.
Loaded symbols for /usr/lib/libXpm.so.4
Reading symbols from /usr/lib/libXmu.so.6...done.
Loaded symbols for /usr/lib/libXmu.so.6
Reading symbols from /usr/lib/libXt.so.6...done.
Loaded symbols for /usr/lib/libXt.so.6
Reading symbols from /usr/lib/libXext.so.6...done.
Loaded symbols for /usr/lib/libXext.so.6
Reading symbols from /usr/lib/libX11.so.6...done.
Loaded symbols for /usr/lib/libX11.so.6
Reading symbols from /usr/lib/libSM.so.6...done.
Loaded symbols for /usr/lib/libSM.so.6
Reading symbols from /usr/lib/libICE.so.6...done.
Loaded symbols for /usr/lib/libICE.so.6
Reading symbols from /lib/libgpm.so.1...done.
Loaded symbols for /lib/libgpm.so.1
Reading symbols from /lib/libncurses.so.5...done.
Loaded symbols for /lib/libncurses.so.5
Reading symbols from /usr/lib/libesd.so.0...done.
Loaded symbols for /usr/lib/libesd.so.0
Reading symbols from /usr/lib/libaudiofile.so.0...done.
Loaded symbols for /usr/lib/libaudiofile.so.0
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /usr/lib/libasound.so.2...done.
Loaded symbols for /usr/lib/libasound.so.2
Reading symbols from /lib/libutil.so.1...done.
Loaded symbols for /lib/libutil.so.1
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /usr/lib/libXp.so.6...done.
Loaded symbols for /usr/lib/libXp.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libpthread.so.0...done.
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 4018)]
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /usr/lib/X11/locale/lib/common/xlcUTF8Load.so.2...done.
Loaded symbols for /usr/lib/X11/locale/lib/common/xlcUTF8Load.so.2
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /lib/libnss_compat.so.2...done.
Loaded symbols for /lib/libnss_compat.so.2
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libnss_nis.so.2...done.
Loaded symbols for /lib/libnss_nis.so.2
0x1b905fcc in memcpy () from /usr/lib/valgrind/vgpreload_memcheck.so
(gdb) backtraxce[K[K[Kce
#0 0x1b905fcc in memcpy () from /usr/lib/valgrind/vgpreload_memcheck.so
#1 0x080c7c46 in Dynarr_realloc (dy=0x84cbda4, new_size=76) at dynarr.c:137
#2 0x080c7d4a in Dynarr_resize (d=0x84cbda4, size=52) at dynarr.c:211
#3 0x0823cfb5 in recalculate_unicode_precedence () at unicode.c:1097
#4 0x081b1d74 in make_charset (id=172, name=471471428, rep_bytes=3, type=1, columns=1,
graphic=1, final=89 'Y', direction=0,
short_name=473432116, long_name=473432148, doc=473432052, reg=473432180, overwrite=0)
at mule-charset.c:272
#5 0x081b28de in Fmake_charset (name=471471428, doc_string=473432052, props=471384820) at
mule-charset.c:613
#6 0x080dd704 in Ffuncall (nargs=4, args=0x52bfb334) at eval.c:3893
#7 0x0809e5a1 in execute_optimized_program (
program=0x52bfb490
"ÁÂ!¬UÃÂÄÅÆÇÈ\"\002ÉÊ\"#\210ËÌ!\210ÍÎÏÐ#\210Ñ\211\030ÒX«\017ÓÔÂ\b\"Õ\"\210\bT\211\020ªï)Ö×Ø\"\210ÓÔÂÙ\"Õ\"\210ÓÔÂÚ\"Û\"\210ÓÔÂÜ\"Û\"\210ÓÔÂÒ\"Ý\"\210Ï\207",
stack_depth=7, constants_data=0x1c188d10) at bytecode.c:862
#8 0x080a3612 in Fbyte_code (instructions=473431972, constants=471371008, stack_depth=15)
at bytecode.c:2620
#9 0x080dc55f in Feval (form=472443820) at eval.c:3646
#10 0x0819f75e in readevalloop (readcharfun=468835992, sourcename=473431300,
evalfun=0x80dbd51 <Feval>, printflag=0)
at lread.c:1466
#11 0x0819da00 in Fload_internal (file=473431300, noerror=137518612, nomessage=137477836,
nosuffix=137518612,
codesys=137500588, used_codesys=137518612) at lread.c:767
#12 0x080dd7d3 in Ffuncall (nargs=6, args=0x52bfbb84) at eval.c:3893
#13 0x0809e5a1 in execute_optimized_program (program=0x8498eb4
"Æ\016\036!\035Ç\rÈ\"\031É\034\t«\f\tÈ\r\b\016\035\n%\202\205",
stack_depth=11, constants_data=0x83e2e68) at bytecode.c:862
#14 0x080dd2eb in funcall_compiled_function (fun=138874824, nargs=4, args=0x52bfbe04) at
eval.c:3492
#15 0x080dd9e1 in Ffuncall (nargs=5, args=0x52bfbe00) at eval.c:3932
#16 0x080deedd in call4 (fn=137489812, arg0=473431300, arg1=137518612, arg2=137477836,
arg3=137518612) at eval.c:4597
#17 0x0813b2a0 in Frequire (feature=471471332, filename=137518612, noerror=137518612) at
fns.c:3602
#18 0x080dd704 in Ffuncall (nargs=2, args=0x52bfbf34) at eval.c:3893
#19 0x0809e5a1 in execute_optimized_program (program=0x52bfc080
"ÀÁ!\210ÀÂ!\210ÀÃ!\210ÀÄ!\210ÅÆ!\207", stack_depth=2,
constants_data=0x1bf5abb8) at bytecode.c:862
#20 0x080a3612 in Fbyte_code (instructions=473431268, constants=469085096, stack_depth=5)
at bytecode.c:2620
#21 0x080dc55f in Feval (form=472443016) at eval.c:3646
#22 0x0819f75e in readevalloop (readcharfun=468967704, sourcename=473430676,
evalfun=0x80dbd51 <Feval>, printflag=0)
at lread.c:1466
#23 0x0819da00 in Fload_internal (file=473430676, noerror=137518612, nomessage=137477836,
nosuffix=137518612,
codesys=137500588, used_codesys=137518612) at lread.c:767
#24 0x080dd7d3 in Ffuncall (nargs=6, args=0x52bfc684) at eval.c:3893
#25 0x0809e5a1 in execute_optimized_program (program=0x8498eb4
"Æ\016\036!\035Ç\rÈ\"\031É\034\t«\f\tÈ\r\b\016\035\n%\202\205",
stack_depth=11, constants_data=0x83e2e68) at bytecode.c:862
#26 0x080dd2eb in funcall_compiled_function (fun=138874824, nargs=4, args=0x52bfc904) at
eval.c:3492
#27 0x080dd9e1 in Ffuncall (nargs=5, args=0x52bfc900) at eval.c:3932
#28 0x080deedd in call4 (fn=137489812, arg0=473430676, arg1=137518612, arg2=137477836,
arg3=137518612) at eval.c:4597
#29 0x0813b2a0 in Frequire (feature=471471308, filename=137518612, noerror=137518612) at
fns.c:3602
#30 0x080dc55f in Feval (form=473506892) at eval.c:3646
#31 0x0819f75e in readevalloop (readcharfun=469081112, sourcename=472277436,
evalfun=0x80dbd51 <Feval>, printflag=0)
at lread.c:1466
#32 0x0819da00 in Fload_internal (file=472277436, noerror=137518612, nomessage=137517772,
nosuffix=137518612,
codesys=137501980, used_codesys=137518612) at lread.c:767
#33 0x080dd7d3 in Ffuncall (nargs=6, args=0x52bfcef4) at eval.c:3893
#34 0x0809e5a1 in execute_optimized_program (program=0x8498eb4
"Æ\016\036!\035Ç\rÈ\"\031É\034\t«\f\tÈ\r\b\016\035\n%\202\205",
stack_depth=11, constants_data=0x83e2e68) at bytecode.c:862
#35 0x080dd2eb in funcall_compiled_function (fun=138874824, nargs=3, args=0x52bfd168) at
eval.c:3492
#36 0x080dd9e1 in Ffuncall (nargs=4, args=0x52bfd164) at eval.c:3932
#37 0x0809e5a1 in execute_optimized_program (program=0x1c27d3d8
"\b\211A\020＠\031ÂÃ\t!!«\005Ã\t!\021Ä\tÅÆ#)\207",
stack_depth=4, constants_data=0x83d2c7c) at bytecode.c:862
#38 0x080dd2eb in funcall_compiled_function (fun=138831880, nargs=1, args=0x52bfd3c8) at
eval.c:3492
#39 0x080dd9e1 in Ffuncall (nargs=2, args=0x52bfd3c4) at eval.c:3932
#40 0x0809e5a1 in execute_optimized_program (program=0x1c27d1d0
"\n¬=\016!?\205Î", stack_depth=7, constants_data=0x83d31c8)
at bytecode.c:862
#41 0x080dd2eb in funcall_compiled_function (fun=138832716, nargs=0, args=0x52bfd628) at
eval.c:3492
#42 0x080dd9e1 in Ffuncall (nargs=1, args=0x52bfd624) at eval.c:3932
#43 0x0809e5a1 in execute_optimized_program (
program=0x1becd1a8 "\vA\035ÆÇ\032\031È\r!\025\bÉa«\004Ê \210ËÌ!«\004Í
\210ËÎ!«\004Ï \210ËÌ!«\017ËÐ!«\aÑÒ!\210ª\004Ó \210\f«\017\016&¬\vÔÕÖ\f!×Q! \210Ø
\210*Ù \210ËÚ!«\004Û \210Ü \210rÝÞ!q\210ß \210àá!\210\016*âa«\005\016+ \210ã \210)ä åa«\bæ
¬\004ç \210è \210á\026,æ \004éÇ!)\207", stack_depth=4, constants_data=0x83d4e94) at
bytecode.c:862
#44 0x080dd2eb in funcall_compiled_function (fun=138837600, nargs=0, args=0x52bfd888) at
eval.c:3492
#45 0x080dd9e1 in Ffuncall (nargs=1, args=0x52bfd884) at eval.c:3932
#46 0x0809e5a1 in execute_optimized_program (
program=0x1bf41950 "\n«\005ÆÇ!\207È\022ÉÊ!«\tËÌÉÊ!!!\210Í
\211\034«\025\fG\rGW«\016Î\r!Î\f!k«\005Ï\f!\025)Ð\r!\025Ñ \210Ò
\210Ó\016(«\004Ȫ\006\016)\002ÔÕ\"\210Ö \210× \210Õ\033Ø «\006Ù
\210ª\006ÚÛÜ\217\210Ð\r!\025\t«\rÝÞß\tà á $!\026*âã!\210\b«\005âÀ!\210Õ\020ä
\210\016%«\005âå!\210Õ\026%\v«\bæ\v＠\vA\"\210)\016+\003ç \207", stack_depth=7,
constants_data=0x83d5a5c)
at bytecode.c:862
#47 0x080dd2eb in funcall_compiled_function (fun=138839844, nargs=0, args=0x52bfda40) at
eval.c:3492
#48 0x080dcb5f in Feval (form=137617204) at eval.c:3707
#49 0x080d9525 in condition_case_1 (handlers=137514460, bfun=0x80dbd51 <Feval>,
barg=137617204, hfun=0x80acc13 <cmd_error>,
harg=137518612) at eval.c:1924
#50 0x080accb0 in top_level_1 (unused_dummy=137518612) at cmdloop.c:223
#51 0x080d8fc2 in internal_catch (tag=137267596, func=0x80acc6e <top_level_1>,
arg=137518612, threw=0x0, thrown_tag=0x0,
backtrace_before_throw=0x0) at eval.c:1530
#52 0x080acdb0 in initial_command_loop (load_me=137518612) at cmdloop.c:293
#53 0x080d2d36 in xemacs_21_5_b25_i686_pc_linux (argc=25, argv=0x52bfded4,
unused_envp=0x0, restart=0) at emacs.c:2666
#54 0x080d3717 in main (argc=25, argv=0x52bfded4, unused_envp=0x52bfdf3c) at emacs.c:3110
(gdb) quit
The program is running. Quit anyway (and detach it)? (y or n)
linux-nat.c:1018: internal-error: linux_nat_detach: Assertion `num_lwps == 1' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) linux-nat.c:1018: internal-error: linux_nat_detach:
Assertion `num_lwps == 1' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) ==4018==
==4018== Debugger has detached. Valgrind regains control. We continue.
==4018==
==4018== Invalid write of size 1
==4018== at 0x1B905FD2: memcpy (in /usr/lib/valgrind/vgpreload_memcheck.so)
==4018== by 0x80C7C45: Dynarr_realloc (dynarr.c:137)
==4018== by 0x80C7D49: Dynarr_resize (dynarr.c:211)
==4018== by 0x823CFB4: recalculate_unicode_precedence (unicode.c:1097)
==4018== by 0x81B1D73: make_charset (mule-charset.c:272)
==4018== by 0x81B28DD: Fmake_charset (mule-charset.c:613)
==4018== by 0x80DD703: Ffuncall (eval.c:3893)
==4018== by 0x809E5A0: execute_optimized_program (bytecode.c:862)
==4018== by 0x80A3611: Fbyte_code (bytecode.c:2620)
==4018== by 0x80DC55E: Feval (eval.c:3646)
==4018== by 0x819F75D: readevalloop (lread.c:1466)
==4018== by 0x819D9FF: Fload_internal (lread.c:767)
==4018== Address 0x1BF68D66 is 2 bytes before a block of size 1200 alloc'd
==4018== at 0x1B90524A: calloc (in /usr/lib/valgrind/vgpreload_memcheck.so)
==4018== by 0x808B23B: xcalloc (alloc.c:382)
==4018== by 0x808B27C: xmalloc_and_zero (alloc.c:391)
==4018== by 0x80CFC0B: resize_hash_table (elhash.c:1069)
==4018== by 0x80CFED2: enlarge_hash_table (elhash.c:1126)
==4018== by 0x80D01CC: Fputhash (elhash.c:1199)
==4018== by 0x80C3006: make_directory_hash_table (dired.c:792)
==4018== by 0x819E52B: locate_file_refresh_hashing (lread.c:899)
==4018== by 0x819E595: locate_file_find_directory_hash_table (lread.c:914)
==4018== by 0x819F0DB: locate_file (lread.c:1285)
==4018== by 0x819E4FA: Flocate_file (lread.c:889)
==4018== by 0x80DD73C: Ffuncall (eval.c:3893)
==4018==
==4018== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- ==4018==
==4018== Invalid write of size 1
==4018== at 0x1B905FD9: memcpy (in /usr/lib/valgrind/vgpreload_memcheck.so)
==4018== by 0x80C7C45: Dynarr_realloc (dynarr.c:137)
==4018== by 0x80C7D49: Dynarr_resize (dynarr.c:211)
==4018== by 0x823CFB4: recalculate_unicode_precedence (unicode.c:1097)
==4018== by 0x81B1D73: make_charset (mule-charset.c:272)
==4018== by 0x81B28DD: Fmake_charset (mule-charset.c:613)
==4018== by 0x80DD703: Ffuncall (eval.c:3893)
==4018== by 0x809E5A0: execute_optimized_program (bytecode.c:862)
==4018== by 0x80A3611: Fbyte_code (bytecode.c:2620)
==4018== by 0x80DC55E: Feval (eval.c:3646)
==4018== by 0x819F75D: readevalloop (lread.c:1466)
==4018== by 0x819D9FF: Fload_internal (lread.c:767)
==4018== Address 0x1BF68D65 is 3 bytes before a block of size 1200 alloc'd
==4018== at 0x1B90524A: calloc (in /usr/lib/valgrind/vgpreload_memcheck.so)
==4018== by 0x808B23B: xcalloc (alloc.c:382)
==4018== by 0x808B27C: xmalloc_and_zero (alloc.c:391)
==4018== by 0x80CFC0B: resize_hash_table (elhash.c:1069)
==4018== by 0x80CFED2: enlarge_hash_table (elhash.c:1126)
==4018== by 0x80D01CC: Fputhash (elhash.c:1199)
==4018== by 0x80C3006: make_directory_hash_table (dired.c:792)
==4018== by 0x819E52B: locate_file_refresh_hashing (lread.c:899)
==4018== by 0x819E595: locate_file_find_directory_hash_table (lread.c:914)
==4018== by 0x819F0DB: locate_file (lread.c:1285)
==4018== by 0x819E4FA: Flocate_file (lread.c:889)
==4018== by 0x80DD73C: Ffuncall (eval.c:3893)
==4018==
==4018== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- ==4018==
==4018== Invalid write of size 1
==4018== at 0x1B905FE3: memcpy (in /usr/lib/valgrind/vgpreload_memcheck.so)
==4018== by 0x80C7C45: Dynarr_realloc (dynarr.c:137)
==4018== by 0x80C7D49: Dynarr_resize (dynarr.c:211)
==4018== by 0x823CFB4: recalculate_unicode_precedence (unicode.c:1097)
==4018== by 0x81B1D73: make_charset (mule-charset.c:272)
==4018== by 0x81B28DD: Fmake_charset (mule-charset.c:613)
==4018== by 0x80DD703: Ffuncall (eval.c:3893)
==4018== by 0x809E5A0: execute_optimized_program (bytecode.c:862)
==4018== by 0x80A3611: Fbyte_code (bytecode.c:2620)
==4018== by 0x80DC55E: Feval (eval.c:3646)
==4018== by 0x819F75D: readevalloop (lread.c:1466)
==4018== by 0x819D9FF: Fload_internal (lread.c:767)
==4018== Address 0x1BF68D64 is 4 bytes before a block of size 1200 alloc'd
==4018== at 0x1B90524A: calloc (in /usr/lib/valgrind/vgpreload_memcheck.so)
==4018== by 0x808B23B: xcalloc (alloc.c:382)
==4018== by 0x808B27C: xmalloc_and_zero (alloc.c:391)
==4018== by 0x80CFC0B: resize_hash_table (elhash.c:1069)
==4018== by 0x80CFED2: enlarge_hash_table (elhash.c:1126)
==4018== by 0x80D01CC: Fputhash (elhash.c:1199)
==4018== by 0x80C3006: make_directory_hash_table (dired.c:792)
==4018== by 0x819E52B: locate_file_refresh_hashing (lread.c:899)
==4018== by 0x819E595: locate_file_find_directory_hash_table (lread.c:914)
==4018== by 0x819F0DB: locate_file (lread.c:1285)
==4018== by 0x819E4FA: Flocate_file (lread.c:889)
==4018== by 0x80DD73C: Ffuncall (eval.c:3893)
==4018==
==4018== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ----
Loading /src/xemacs/lib/xemacs-21.5-b25/lisp/cl-macs.elc...
Requiring
/src/xemacs/packages/mule-packages/latin-euro-standards/latin-euro-latin8.elc...
Requiring
/src/xemacs/packages/mule-packages/latin-euro-standards/latin-euro-latin9.elc...
Requiring
/src/xemacs/packages/mule-packages/latin-euro-standards/latin-euro-latin10.elc...
Compiling /src/xemacs/packages/mule-packages/latin-unity/auto-autoloads.el...
Wrote /src/xemacs/packages/mule-packages/latin-unity/auto-autoloads.elc
Done
==4018==
==4018== ERROR SUMMARY: 52 errors from 4 contexts (suppressed: 67 from 1)
==4018== malloc/free: in use at exit: 2835234 bytes in 5844 blocks.
==4018== malloc/free: 117662 allocs, 111818 frees, 33279611 bytes allocated.
==4018== For counts of detected errors, rerun with: -v
==4018== searching for pointers to 5844 not-freed blocks.
==4018== checked 7797524 bytes.
==4018==
==4018==
==4018== 68 bytes in 1 blocks are possibly lost in loss record 21 of 59
==4018== at 0x1B90524A: calloc (in /usr/lib/valgrind/vgpreload_memcheck.so)
==4018== by 0x1B8F1ED4: allocate_dtv (in /lib/ld-2.3.5.so)
==4018== by 0x1B8F1F83: _dl_allocate_tls_storage (in /lib/ld-2.3.5.so)
==4018== by 0x1B8F21A2: _dl_allocate_tls (in /lib/ld-2.3.5.so)
==4018== by 0x1BE6956C: __pthread_initialize_minimal (in /lib/libpthread-0.10.so)
==4018== by 0x1BE662A4: ??? (crti.S:19)
==4018== by 0x1BE65C9B: ??? (crti.S:32)
==4018== by 0x1B8EF97A: call_init (in /lib/ld-2.3.5.so)
==4018== by 0x1B8EFAC3: _dl_init (in /lib/ld-2.3.5.so)
==4018== by 0x1B8E480E: (within /lib/ld-2.3.5.so)
==4018==
==4018==
==4018== 156 (36 direct, 120 indirect) bytes in 1 blocks are definitely lost in loss
record 25 of 59
==4018== at 0x1B9043E4: malloc (in /usr/lib/valgrind/vgpreload_memcheck.so)
==4018== by 0x1BE02450: (within /lib/libc-2.3.5.so)
==4018== by 0x1BE02CBA: __nss_database_lookup (in /lib/libc-2.3.5.so)
==4018== by 0x1C0F106B: ???
==4018== by 0x1C0F2094: ???
==4018== by 0x1BDC28F1: getpwnam_r (in /lib/libc-2.3.5.so)
==4018== by 0x1BDC23F9: getpwnam (in /lib/libc-2.3.5.so)
==4018== by 0x822A8E9: qxe_getpwnam (sysdep.c:3443)
==4018== by 0x80CA80E: Fuser_full_name (editfns.c:786)
==4018== by 0x80C84E7: init_editfns (editfns.c:100)
==4018== by 0x80D2B8D: xemacs_21_5_b25_i686_pc_linux (emacs.c:2586)
==4018== by 0x80D3716: main (emacs.c:3110)
==4018==
==4018==
==4018== 1596 (252 direct, 1344 indirect) bytes in 21 blocks are definitely lost in loss
record 34 of 59
==4018== at 0x1B9043E4: malloc (in /usr/lib/valgrind/vgpreload_memcheck.so)
==4018== by 0x808B1AB: xmalloc (alloc.c:370)
==4018== by 0x810AD26: allocate_extent_list (extents.c:984)
==4018== by 0x810B023: allocate_extent_info (extents.c:1318)
==4018== by 0x810B4CB: init_buffer_extents (extents.c:1471)
==4018== by 0x80951AD: finish_init_buffer (buffer.c:633)
==4018== by 0x80952DA: Fget_buffer_create (buffer.c:684)
==4018== by 0x80DD6B5: Ffuncall (eval.c:3893)
==4018== by 0x809E5A0: execute_optimized_program (bytecode.c:862)
==4018== by 0x80DD2EA: funcall_compiled_function (eval.c:3492)
==4018== by 0x80DD9E0: Ffuncall (eval.c:3932)
==4018== by 0x809E5A0: execute_optimized_program (bytecode.c:862)
==4018==
==4018==
==4018== 2720 bytes in 1 blocks are possibly lost in loss record 54 of 59
==4018== at 0x1B9054C3: memalign (in /usr/lib/valgrind/vgpreload_memcheck.so)
==4018== by 0x1B8F1F54: _dl_allocate_tls_storage (in /lib/ld-2.3.5.so)
==4018== by 0x1B8F21A2: _dl_allocate_tls (in /lib/ld-2.3.5.so)
==4018== by 0x1BE6956C: __pthread_initialize_minimal (in /lib/libpthread-0.10.so)
==4018== by 0x1BE662A4: ??? (crti.S:19)
==4018== by 0x1BE65C9B: ??? (crti.S:32)
==4018== by 0x1B8EF97A: call_init (in /lib/ld-2.3.5.so)
==4018== by 0x1B8EFAC3: _dl_init (in /lib/ld-2.3.5.so)
==4018== by 0x1B8E480E: (within /lib/ld-2.3.5.so)
==4018==
==4018==
==4018== 8192 bytes in 1 blocks are possibly lost in loss record 56 of 59
==4018== at 0x1B9043E4: malloc (in /usr/lib/valgrind/vgpreload_memcheck.so)
==4018== by 0x808B1AB: xmalloc (alloc.c:370)
==4018== by 0x808DE42: init_string_chars_alloc (alloc.c:2405)
==4018== by 0x8092279: common_init_alloc_early (alloc.c:4855)
==4018== by 0x80923ED: reinit_alloc_early (alloc.c:4967)
==4018== by 0x80D276D: xemacs_21_5_b25_i686_pc_linux (emacs.c:1874)
==4018== by 0x80D3716: main (emacs.c:3110)
==4018==
==4018== LEAK SUMMARY:
==4018== definitely lost: 288 bytes in 22 blocks.
==4018== indirectly lost: 1464 bytes in 52 blocks.
==4018== possibly lost: 10980 bytes in 3 blocks.
==4018== still reachable: 2822502 bytes in 5767 blocks.
==4018== suppressed: 0 bytes in 0 blocks.
==4018== Reachable blocks (those to which a pointer was found) are not shown.
==4018== To see them, rerun with: --show-reachable=yes
----------------------------------------------------------------------
Yours
--
%% Mats
9:30 p.m.
>>>>"ML" == Mats Lidell <matsl(a)xemacs.org>
writes:
ML> OK. Doing make in ".../mule-packages/latin-unit" is one way
of
ML> getting the problem. It is very reliable also. Happens all the
ML> time which makes the analysis a bit easier.
Thanks a lot for your effort, Mats. I was able to reproduce the bug
following your recipe. I've just commited a patch that fixes it for
me. Please test if current cvs also fixes it for you.
--
Marcus
12:20 a.m.
>>>> Marcus wrote:
Marcus> Thanks a lot for your effort, Mats. I was able to reproduce
Marcus> the bug following your recipe. I've just commited a patch
Marcus> that fixes it for me. Please test if current cvs also fixes
Marcus> it for you.
Yes it works fine now.
Yours
--
%% Mats
1:19 p.m.
>>>> "Mats" == Mats Lidell
<matsl(a)xemacs.org> writes:
Mats> Adrian Aichner wrote:
> Mats Lidell <matsl(a)xemacs.org> writes:
>
> Mats, I'm not sure, but it looks as if you have note enabled the new
> incremental garbage collector itself.
>
> Try again with --enable-newgc
Mats> Using the newgc made the memory problem go way. That made my day
Mats> but someone should maybe look out for this and why it occured in
Mats> the first place. Maybe all 21.5 users are using the new newgc,
Mats> ;-), or have not synced with CVS lately, :-(.
Certainly not all of them -- I have just invested significant effort
into trying to narrow down the problem I had. XEmacs was crashing, with
symptoms very similar to yours. 21.5.24 was not showing this
problem. I've tried using, one after another, --disable-kkcc disabling
--with-optimization and enabling error checking. I was not using
--enable-newgc.
I did not realize that --enable-newgc is completely independent from
--enable-kkcc. If there is an intention of keeping the old code around,
perhaps better descriptions should be provided in configure? (as in
--with-gc=vanilla for folks who want to go back to a working default)
--J.
2:35 p.m.
>>>>"JR" == Jan Rychter <jan(a)rychter.com>
writes:
JR> I did not realize that --enable-newgc is completely independent
JR> from --enable-kkcc.
NEWGC is not independent from KKCC. KKCC is a prerequisite of NEWGC.
If you configure with --enable-newgc, configure turns on KKCC.
We have a separate configure option for it because KKCC can also be
used with the old allocator/garbage collector.
JR> If there is an intention of keeping the old code around, perhaps
JR> better descriptions should be provided in configure? (as in
JR> --with-gc=vanilla for folks who want to go back to a working
JR> default)
The options --enable-kkcc and --enable-newgc are the only options that
mess with gc-related code. NEWGC is still defaulted to off, so people
have to explicitly add this option to the configure string. Thus, I
assume they know what they are doing.
And that KKCC is turned on by default is not a secret, see the output
of configure:
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: ---------------------------------------------------------
You can turn off KKCC, then you will not find any gc-related output in
your Installation file. This means that you use the old allocator and
the old garbage collector. Although it might not be a "working" one
either, my last patch might have introduced some problems with the old
collector as well. I am still trying to figure this out, so gdb
and/or valgrind output of your crashes can be helpful.
--
Marcus
10:19 a.m.
>>>> "Jan" == Jan Rychter
<jan(a)rychter.com> writes:
Jan> I did not realize that --enable-newgc is completely
Jan> independent from --enable-kkcc. If there is an intention of
Jan> keeping the old code around, perhaps better descriptions
Jan> should be provided in configure? (as in --with-gc=vanilla
Jan> for folks who want to go back to a working default)
There is no guarantee of a working default in the beta series.
The only way to get something close to a guarantee is a feature
freeze. We're not ready for that.
--
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.
5 p.m.
>>>>> "Jan" == Jan Rychter
<jan(a)rychter.com> writes:
Jan> I did not realize that --enable-newgc is completely
Jan> independent from --enable-kkcc. If there is an intention of
Jan> keeping the old code around, perhaps better descriptions
Jan> should be provided in configure? (as in --with-gc=vanilla
Jan> for folks who want to go back to a working default)
There is no guarantee of a working default in the beta series.
The only way to get something close to a guarantee is a feature
freeze. We're not ready for that.
I was just making a suggestion that would make life easier for some
people. Yes, I know it's a beta, yes, I know there are no guarantees.
I wasn't complaining, as you might have noticed, just suggesting.
Does the Beta-ness of the beta series mean we should not aim for
well-documented config options?
--J.
12:05 a.m.
Jan Rychter <jan(a)rychter.com> writes:
> >>>>> "Jan" == Jan Rychter
<jan(a)rychter.com> writes:
> Jan> I did not realize that --enable-newgc is completely
> Jan> independent from --enable-kkcc. If there is an intention of
> Jan> keeping the old code around, perhaps better descriptions
> Jan> should be provided in configure? (as in --with-gc=vanilla
> Jan> for folks who want to go back to a working default)
>
> There is no guarantee of a working default in the beta series.
>
> The only way to get something close to a guarantee is a feature
> freeze. We're not ready for that.
I was just making a suggestion that would make life easier for some
people. Yes, I know it's a beta, yes, I know there are no guarantees.
I wasn't complaining, as you might have noticed, just suggesting.
Thanks for your valuable feedback, Jan!
Does the Beta-ness of the beta series mean we should not aim for
well-documented config options?
No.
What should we do about this?
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
3:25 a.m.
>>>> "APA" == Adrian Aichner
<adrian(a)xemacs.org> writes:
APA> Jan Rychter <jan(a)rychter.com> writes:
> I was just making a suggestion that would make life easier for
> some people. Yes, I know it's a beta, yes, I know there are no
> guarantees. I wasn't complaining, as you might have noticed,
> just suggesting.
I realized that. I was reminding you that there are reasons why there
are no guarantees; I'll spell them out below.
Executive summary: I doubt anybody but Marcus could properly document
the current bugginess (i.e., explain who should use which combination
of options under what circumstances); isn't it preferable that he
spend the time on *fixing* it?
> Does the Beta-ness of the beta series mean we should not aim
> for well-documented config options?
APA> No.
APA> What should we do about this?
IMO, nothing in the options documentation, at least not along the
lines of what Jan is suggesting. The documentation of the options is
correct as far as I can see. If you want to know what those options
actually do when enabled, see Marcus's home page. There's a pointer
at http://www.xemacs.org/People/marcus.crestani/, IIRC the URL.
The code pertaining to the --enable-kkcc setup should be fixed, if it
can be done with minimal effort, or if no workarounds can be found
for some class of testers. Marcus is actively working on the code,
although I think he's currently concentrating on the newgc side rather
than the KKCC side.
(0) "Ordinary users" can always back up to the last usable version.
If they do use features that are basically only available in CVS HEAD,
they're "testers" (whether they want to be or not ;-). But most of
the important features, e.g., Mule on Windows, are available in
reasonably stable, reasonably fresh beta releases.
(1) --with-kkcc SHOULD be backward-compatible with the old collector.
Experience has shown it to be so. And Marcus went to some trouble to
ensure that in his recent refactoring, from my brief review of the
patch. Perhaps he should have tried harder, but AFAIK only Marcus can
judge that very well. :-)
(2) --with-mc-alloc was designed to be incompatible, as was --with-newgc.
Both have had some bugs. Marcus made the decision to refactor those
into a single set of #ifdef's, and IMHO did a pretty good job of it,
along the right lines (ie, leave --with-kkcc as a separate option and
on by default).
This means that the garbage collector code is unstable; this was
mentioned in the announcement of 21.5.25. But Marcus is patching it
on a nearly daily basis; any documentation we put into the configure
script will probably be obsolete within a week or two.
That is the nature of the mainline.
--
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.
6603
days inactive
6612
days old
16 comments
6 participants
participants (6)
-
Adrian Aichner -
Jan Rychter -
Malcolm Purvis -
Marcus Crestani -
Stephen J. Turnbull -
The XEmacs Package Smoketest