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.

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&gt;

Jerry James <james(a)xemacs.org&gt; writes: 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

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

Reiner> On Tue, Mar 14 2006, Stephen J. Turnbull wrote: 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.

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