GC crash in 21.2.37 under Linux
23 years, 5 months
Karl Kleinpaste
Karl Kleinpaste
Under RH6.2, I've gotten cores in .37 when running "gnuclient -nw"
during Gnus use.
Core was generated by `xemacs -geometry 205x86+1282+0 -f gnus-init'.
Program terminated with signal 11, Segmentation fault.
[ a couple dozen "Reading symbols from " removed. ]
#0 0x4033dd21 in __kill () from /lib/libc.so.6
(gdb) bt
#0 0x4033dd21 in __kill () from /lib/libc.so.6
#1 0x80b13be in fatal_error_signal (sig=11) at emacs.c:531
#2 0x4033dc48 in __restore ()
at ../sysdeps/unix/sysv/linux/i386/sigaction.c:127
#3 0x808731c in garbage_collect_1 () at alloc.c:3184
#4 0x80b47ad in Ffuncall (nargs=2, args=0xbfffe734) at eval.c:3477
#5 0x809047e in execute_optimized_program (
program=0x8931118 "ÆÇÈ!!\036*É\216r\016*q\210Ê\016-!Ê\016.!ÊË!ÌÍ", '\211' <repeats 11 times>, "\034\036#\036%\036/\036&\032\036$\e\0360\035\0361\0362\030\036+\036'\036(ÎÏ\t!!\031Ð\016,!\210\tc\210Ñ \210eb\210)Ò\016,!\036)ÓÔÕ\016)#\210ÓÖÕ\016)#\210Ð\016)!\210)Íf\211\025\016(s\205\t\001\r\016's?\205\001\001`×Ø!\210`{\227\026&m\204á", stack_depth=17, constants_data=0x87393c8) at bytecode.c:746
#6 0x8090144 in funcall_compiled_function (fun=141695928, nargs=1,
args=0xbfffe860) at bytecode.c:515
#7 0x80b4aff in Ffuncall (nargs=2, args=0xbfffe85c) at eval.c:3563
#8 0x809047e in execute_optimized_program (program=0x8840a28 "ÁÂ\b!!\207ÿÿ ",
stack_depth=3, constants_data=0x8739388) at bytecode.c:746
#9 0x8090144 in funcall_compiled_function (fun=141695900, nargs=1,
args=0xbfffe8e4) at bytecode.c:515
#10 0x80b43b5 in Feval (form=143507936) at eval.c:3388
#11 0x80b2640 in condition_case_3 (bodyform=143507936, var=136511380,
handlers=143507888) at eval.c:1651
#12 0x8090da3 in execute_rare_opcode (stack_ptr=0xbfffeaf4,
program_ptr=0x8930bdf "\025\016$«\006ÐÑ!ª\b\r\005Ò\rÃ\"\023\r\005Ò\rÂ\"\022\f«\005Ó\f!\024\r«\nÔÕ\r＠\"¬\003Ç\025db\210)Öy\210\214`d}\210\b×a«\tØ Ùa«\003\b\023\r«\a\r＠Úk\023\n?\017Û\013\f\aÜÝ\f!\227!\r(a)#.\f\207e)",
opcode=Bcondition_case) at bytecode.c:1271
#13 0x80902cb in execute_optimized_program (
program=0x8930ba8 "Æ\211Ç\016\036\212ÇÈÉ\217\210\016\037)Ç\211\211\211\211\032\e\035\034\031\036 \030\036!\036\"\036#\212\214Ê \210ËÌÆ\"\021ËÍÆ\"\024\t\005ÇÎÏ\217\025\016$«\006ÐÑ!ª\b\r\005Ò\rÃ\"\023\r\005Ò\rÂ\"\022\f«\005Ó\f!\024\r«\nÔÕ\r＠\"¬\003Ç\025db\210)Öy\210\214`d}\210\b×a«\tØ Ùa«\003\b\023\r«\a\r＠Úk\023\n?\017Û\013\f\aÜÝ\f!\227!\r(a)#.\f\207e)", stack_depth=10,
constants_data=0x8997cd0) at bytecode.c:656
#14 0x8090144 in funcall_compiled_function (fun=144274612, nargs=0,
args=0xbfffecf0) at bytecode.c:515
#15 0x80b4aff in Ffuncall (nargs=1, args=0xbfffecec) at eval.c:3563
#16 0x80b53f2 in run_hook_with_args_in_buffer (buf=0x8c552e8, nargs=1,
args=0xbfffecec, cond=RUN_HOOKS_TO_COMPLETION) at eval.c:4020
#17 0x80b7d03 in run_hook_with_args (nargs=1, args=0xbfffecec,
cond=RUN_HOOKS_TO_COMPLETION) at eval.c:4033
#18 0x80b9780 in Frun_hooks (nargs=1, args=0xbfffecec) at eval.c:3887
#19 0x80b4ab0 in Ffuncall (nargs=2, args=0xbfffece8) at eval.c:3549
#20 0x809047e in execute_optimized_program (
program=0x89874f8 "Æ\211\0363\0362\212Ç \210È \210\f®\003\0164\024\r;«\005É\r!\210\r§\203\222", stack_depth=6, constants_data=0x896ad38) at bytecode.c:746
#21 0x8090144 in funcall_compiled_function (fun=144167732, nargs=2,
args=0xbfffede4) at bytecode.c:515
#22 0x80b4aff in Ffuncall (nargs=3, args=0xbfffede0) at eval.c:3563
#23 0x809047e in execute_optimized_program (
program=0x8923788 "\212\0164Æa¬\004\bq\210p\020\016-«\a\016-ÇHª\002\r\0365p\036*\0166\0367\016+\036.È\e\212É \210\0168q\210ÊË!«\b\016\013«\004È\0269È\036:Ì\r\016.\")\211\023\204\214", stack_depth=4, constants_data=0x8994508)
at bytecode.c:746
#24 0x8090144 in funcall_compiled_function (fun=144276376, nargs=2,
args=0xbfffeed8) at bytecode.c:515
#25 0x80b4aff in Ffuncall (nargs=3, args=0xbfffeed4) at eval.c:3563
#26 0x809047e in execute_optimized_program (
program=0x89a6350 "Æ \210\n\211\034\013Ç\f!\006ÈÇ\f!!)«&r\nq\210\016\032\026\e\016\034\026\035ÉÊ!«\024ËÌ!«\017ÍÌ!«\nÎÏ!¬\005ÊÐ!\210)\r9\t«\a\t\r\b\"ª\005Ñ\r\b\"ÒÓ!\210\013«\n\013ÔU¬\005Õ\013!\210Ö \210\016\036«\r\016\037«\t×\r!\210Ø\r!\210Ù\r\016 ·A!\210\207", stack_depth=5, constants_data=0x8891758)
at bytecode.c:746
#27 0x8090144 in funcall_compiled_function (fun=143217236, nargs=2,
args=0xbfffefd0) at bytecode.c:515
#28 0x80b4aff in Ffuncall (nargs=3, args=0xbfffefcc) at eval.c:3563
#29 0x809047e in execute_optimized_program (
program=0x8bfb690 "\016\036Æa¬\005\016\032q\210\r®\030Ç`È\"\211\036\e«\006É\016\e!\210)Ç`Ê\"®\003Ë \f??Ì\036\037\034\035\016 ¬\nÍ\r!«\005ÎÏ!\210\212\016\032q\210\016\034«\031\013«&\n«#Ð\t!«\036\r\nAa«\030\n＠\016!k«\021\016\034¬\t\013«\n\013\ra«\005\016\"«DÑ\r\f\"\210\t\211\030\013Ð\b!\006ÒÐ\b!!)«\030r\tq\210\016#¬\017ÓÔ!«\nÕÖ!¬\005ÔÌ!\210)\f¬\005\016\035«\004× \210Ø\r\016$·A!\210\rª\f\f¬\005\016\035«\004× \210Ù,\207", stack_depth=4, constants_data=0x88917f0)
at bytecode.c:746
#30 0x8090144 in funcall_compiled_function (fun=143217264, nargs=2,
args=0xbffff0c4) at bytecode.c:515
#31 0x80b4aff in Ffuncall (nargs=3, args=0xbffff0c0) at eval.c:3563
#32 0x809047e in execute_optimized_program (
program=0x8b97b88 "\f§«f\f\016%·A®\004ÆÇ!È\036&\036'ÉÊË\"\210\016(Ê\211\035\e\030\212\016)q\210\214Ì \210Í \023)ÎÏÐ!!\036!Ñ\216r\016!q\210ÒÓ\nA\"c\210\013c\210Ôc\210p\036*Õ\bÖ\"＠\025-\nA\016+·\036\"×\016\"\233\r \210)Ø\nA\r\"\210-ªL\f¬\bÉÊË\"\210ªBÙÚ!\210ÙÛ!\210ÖÊ\211\211\211\036,\036-\036.\036/\0360\016#\211\031\013Ü\t!\006ÝÜ\t!!)«\022\212\016#q\210Þ\016$!\210Ê\211\0261\026$)ÉÊË\"\210-ß\0162!\210à \207a", stack_depth=6, constants_data=0x87a8238) at bytecode.c:746
#33 0x8090144 in funcall_compiled_function (fun=143206376, nargs=1,
args=0xbffff1c4) at bytecode.c:515
#34 0x80b4aff in Ffuncall (nargs=2, args=0xbffff1c0) at eval.c:3563
#35 0x8094524 in Fcall_interactively (function=137785388,
record_flag=136511380, keys=136511380) at callint.c:940
#36 0x80b3986 in Fcommand_execute (cmd=137785388, record_flag=136511380,
keys=136511380) at eval.c:2970
#37 0x80eef42 in execute_command_event (command_builder=0x861ab78,
event=140562240) at event-stream.c:3833
#38 0x80ef6a9 in Fdispatch_event (event=140562240) at event-stream.c:4164
#39 0x809a0dd in Fcommand_loop_1 () at cmdloop.c:583
#40 0x809a2ee in command_loop_1 (dummy=136511380) at cmdloop.c:494
#41 0x80b88cb in condition_case_1 (handlers=136511476,
bfun=0x809a2d8 <command_loop_1>, barg=136511380,
hfun=0x8099c20 <cmd_error>, harg=136511380) at eval.c:1651
#42 0x809a3cc in command_loop_2 (dummy=136511380) at cmdloop.c:256
#43 0x80b87af in internal_catch (tag=136587644,
func=0x809a394 <command_loop_2>, arg=136511380, threw=0x0) at eval.c:1317
#44 0x8099e5c in initial_command_loop (load_me=136511380) at cmdloop.c:305
#45 0x80af9b4 in sort_args (argc=5, argv=0xbffff6d4) at emacs.c:2231
#46 0x80b15a6 in main () at emacs.c:2660
#47 0x403379cb in __libc_start_main (main=0x80b14a8 <main>, argc=5,
argv=0xbffff6d4, init=0x80813c4 <_init>, fini=0x81bb760 <_fini>,
rtld_fini=0x4000ae60 <_dl_fini>, stack_end=0xbffff6cc)
at ../sysdeps/generic/libc-start.c:92
uname -a: Linux belladonna.iolitemedia.com 2.2.16-k10021 #1 Mon Oct 2 13:48:01 EDT 2000 i686 unknown
./configure '--with-pop' '--with-mule' '--error-checking=none' '--debug=no'
XEmacs 21.2-b37 "Pan" configured for `i686-pc-linux'.
Compilation / Installation:
Source code location: /opt/hell/usr/src/Packages/xemacs/xemacs-21.2.37
Installation prefix: /usr/local
Operating system description file: `s/linux.h'
Machine description file: `m/intel386.h'
Compiler: /usr/bin/gcc -g -O3 -Wall -Wno-switch -Wpointer-arith -Winline -Wmissing-prototypes -Wshadow
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/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.
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:
Compiling in support for Berkeley database.
Compiling in support for GNU DBM.
Compiling in support for LDAP.
Compiling in support for PostgreSQL.
- Using PostgreSQL header file: pgsql/libpq-fe.h
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 POP mail retrieval.
Compiling in support for "dot-locking" mail spool file locking method.
Other Features:
Compiling in support for dynamic shared object modules.
- 1 participants
- 0 comments
RE: Who is the portable dumper expert? 21.2.37 Portable dumper s till broken.
23 years, 5 months
Troy Noble
Troy Noble
Very nice! I am truly amazed at how quickly you went right to the source
of the problem, given the fact you said you haven't looked at the code for
a while. Looks like I was barking up the wrong tree so to speak. I saw
the symptom, but was nowhere near identifying the root cause.
Thanks for fixing this. Will look for the patch after the archive updates
tonight (I'm not on xemacs-patches list).
Thanks again, Troy
-----Original Message-----
From: Olivier Galibert [mailto:galibert＠pobox.com]
Sent: Thursday, November 16, 2000 12:24 AM
To: Troy Noble
Cc: 'xemacs-beta(a)xemacs.org'
Subject: Re: Who is the portable dumper expert? 21.2.37 Portable dumper
s till broken.
On Wed, Nov 15, 2000 at 03:25:24PM -0700, Troy Noble wrote:
> Olivier, thanks for being so gracious.
>
> So here's the situation. I've tried this on both NT with MSVC 5.0 and
> Linux with gcc/gdb using 21.2b36 and 21.2b37.
>
> In src/indent.c there is the following:
>
> void
> vars_of_indent (void)
> {
> DEFVAR_BOOL ("indent-tabs-mode", &indent_tabs_mode /*
> *Indentation can insert tabs if this is non-nil.
> Setting this variable automatically makes it local to the current buffer.
> */ );
> indent_tabs_mode = 1;
> }
>
> When the portable dumper is enabled, setting or clearing this variable has
> no
> effect. It's almost like the portable dumper loads it into memory but
never
> wires up the appropriate forwarding information so that the lisp code
knows
> how to find the variable. I suspect this is true of other such opaque
> variables,
> but haven't proven that conclusively yet.
>
> I do know that if I set "watch indent_tabs_mode" the only time it ever
gets
> set throughout the lifetime of my debug session is at startup time. Any
> subsequent
> calls to (setq-default indent-tabs-mode nil) or (setq indent-tabs-mode
nil)
> have no effect. If I stop the debugger (CTRL-C) and do "p
indent_tabs_mode"
> it's
> always 1. Here's where it gets set initially:
>
> Old value = 0
> New value = 1
> 0x4034e4b3 in memcpy (dstpp=0x8331f7c, srcpp=0x40580f34, len=4)
> at ../sysdeps/generic/memcpy.c:61
> 61 ../sysdeps/generic/memcpy.c: No such file or directory.
> (gdb) bt
> #0 0x4034e4b3 in memcpy (dstpp=0x8331f7c, srcpp=0x40580f34, len=4)
> at ../sysdeps/generic/memcpy.c:61
> #1 0x80c8407 in pdump_load_finish () at dumper.c:1041
> #2 0x80c891d in pdump_load (
> argv0=0xbfffe517 "/usr2/tnoble/build/xemacs-21.2.36/src/./xemacs") at
> dumper.c:1358
> #3 0x80b15e2 in xemacs_21_2_b36_i686_pc_linux (argc=1, argv=0xbfffe284,
> envp=0xbfffe28c, restart=0) at emacs.c:1164
> #4 0x80b3bd1 in main (argc=1, argv=0xbfffe284, envp=0xbfffe28c) at
> emacs.c:2595
>
>
> So am wondering if there is an additional step that might need to be added
> after the opaques are loaded in pdump_load_finish to make them visible to
> lisp. The code in question is:
>
> dumper.c, Line 1041:
>
> /* Put back the opaques */
> for (i=0; i<((dump_header *)pdump_start)->nb_opaquedmp; i++)
> {
> struct pdump_dumpopaqueinfo di = PDUMP_READ (p, struct
> pdump_dumpopaqueinfo);
> > memcpy (di.data, p, di.size);
> p += di.size;
> }
>
>
> Interestingly, when I turn off the portable dumper... I always get a watch
> breakpoint
> at the following location whenever I (setq-default indent-tabs-mode
> <whatever>):
>
> symbols.c, Line 1255:
>
> case SYMVAL_BOOLEAN_FORWARD:
> if (magicfun)
> magicfun (sym, &newval, Qnil, 0);
> *((int *) symbol_value_forward_forward (fwd))
> = !NILP (newval);
> > return;
>
>
> So do these opaques need to be added to the pdump_reloc_table (presumably
> in pdump_dump_rtable and then again when the rtable gets read back in) so
> they get manipulated in pdump_reorganize_hash_table, or is there something
> else that needs to happen?
>
> dumper.c, line 1089 and following:
>
> /* Final cleanups */
> /* reorganize hash tables */
> p = pdump_rt_list;
> for (;;)
> {
> pdump_reloc_table rt = PDUMP_READ (p, pdump_reloc_table);
> if (!rt.desc)
> break;
> if (rt.desc == hash_table_description)
> {
> for (i=0; i < rt.count; i++)
> pdump_reorganize_hash_table (PDUMP_READ (p, Lisp_Object));
> break;
> } else
> p += sizeof (Lisp_Object) * rt.count;
> }
>
> I don't mind doing the legwork, just not sure what direction to head
> at the moment since I've only just started crawling into the code.
>
> Thanks in advance for any direction, Troy
Ah grasshopper, if it was that easy :-)
pdump_reorganize_hash_table is a red herring. It exists only because
most hashcodes are computed from the actual addresses of the objects,
and since said addresses change depending on where the dump file was
loaded they have to be reorganized according to the new hashcodes.
So the question is, is the opaque dumped? If you look at symeval.h you can
see:
#define DEFVAR_BOOL(lname, c_location) \
DEFVAR_SYMVAL_FWD_INT (lname, c_location, SYMVAL_BOOLEAN_FORWARD, 0)
#define DEFVAR_SYMVAL_FWD_INT(lname, c_location, forward_type, magicfun) do{
\
DEFVAR_SYMVAL_FWD (lname, c_location, forward_type, magicfun);
\
dumpopaque (c_location, sizeof(int));
\
} while (0)
If you look at what dumpopaque does, you can see that it does what's
expected. I can even tell you that it does it correctly (I checked,
and anyway all C-accessible variables would explode if is wasn't
working, so it can't be that bad. I mean, XEmacs would not start at
all).
So The Truth is Somewhere Else(c)(r)(tm). You found (thanks, that's
exactly the starting point needed) a discrepancy of behaviour in the C
code between pdump and normal. If you check a bit deeper you can see
that is the pdump case the code never goes near the case
SYMVAL_BOOLEAN_FORWARD: for the symbol indent-tabs-mode. So let's
fish out the symbol and compare between pdump and normal:
With --pdump:
In *scratch* "(setq indent-tabs-mode nil)^C"
Program received signal SIGINT, Interrupt.
0x403c815e in __select () from /lib/libc.so.6
(gdb) break oblookup
Breakpoint 1 at 0x82001ce: file
/home/galibert/xemacs/xemacs-21.2/src/symbols.c, line 348.
(gdb) cond 1 size==16
(gdb) cont
Continuing.
In *scratch* "^J" (aka, execute line)
Breakpoint 1, oblookup (obarray=1079809524, ptr=0x85dc1ac
"indent-tabs-mode", size=16) at
/home/galibert/xemacs/xemacs-21.2/src/symbols.c:348
(gdb) finish
Run till exit from #0 oblookup (obarray=1079809524, ptr=0x85dc1ac
"indent-tabs-mode", size=16)
at /home/galibert/xemacs/xemacs-21.2/src/symbols.c:348
0x81ffc90 in Fintern (string=139009716, obarray=1079809524) at
/home/galibert/xemacs/xemacs-21.2/src/symbols.c:216
216 object = oblookup (obarray, XSTRING_DATA (string), len);
Value returned is $1 = 1078992296
(gdb) pobj $1
$2 = (Lisp_Symbol *) 0x40501da8
$3 = {lheader = {type = 4, mark = 0, c_readonly = 0, lisp_readonly = 0},
next = 0x0, name = 0x404837a0, value = 1079230256,
function = 1078786304, plist = 1079592596}
Symbol name: indent-tabs-mode
(gdb) pobj $2->value
$4 = (struct symbol_value_buffer_local *) 0x4053bf30
$5 = {magic = {lcheader = {lheader = {type = 3, mark = 0, c_readonly = 0,
lisp_readonly = 0}, next = 0x857f7c0, uid = 7892, free = 0},
value = 0x2, type = SYMVAL_BUFFER_LOCAL}, default_value = 1079009624,
current_value = 1079010440, current_buffer = 1079010440,
current_alist_element = 1079010440}
(gdb) pobj $4->default_value
$6 = (Lisp_Symbol *) 0x40506158
$7 = {lheader = {type = 4, mark = 0, c_readonly = 0, lisp_readonly = 0},
next = 0x0, name = 0x40487410, value = 1079009624,
function = 1078786304, plist = 1079010440}
Symbol name: t
(gdb) pobj $4->current_value
$8 = (Lisp_Symbol *) 0x40506488
$9 = {lheader = {type = 4, mark = 0, c_readonly = 0, lisp_readonly = 0},
next = 0x0, name = 0x404876d0, value = 1079010440,
function = 1078786304, plist = 1079010440}
Symbol name: nil
Hum hum, so the symbol is in fact a buffer local one. And there is no
sign of SYMVAL_BOOLEAN_FORWARD anywhere. Ok, let's try without pdump:
(gdb) pobj $4->default_value
$6 = (Lisp_Symbol *) 0x832bc4c
$7 = {lheader = {type = 4, mark = 0, c_readonly = 0, lisp_readonly = 0},
next = 0x0, name = 0x832b44c, value = 137542732, function = 137166796,
plist = 137542708}
Symbol name: t
(gdb) pobj $4->current_value
$8 = (struct symbol_value_forward *) 0x82b2d58
$9 = {magic = {lcheader = {lheader = {type = 0, mark = 1, c_readonly = 1,
lisp_readonly = 1}, next = 0x0, uid = 0, free = 0}, value = 0x8306c1c,
type = SYMVAL_BOOLEAN_FORWARD}, magicfun = 0}
We have a winner. The symbol is hosed. Time to have a look at the
struct symbol_value_buffer_local declaration and its description.
Just go in symeval.h and read it. I obviously didn't have my brain
engaged when I read it a long time ago, given what I wrote as a
description:
static const struct lrecord_description
symbol_value_buffer_local_description[] = {
{ XD_LISP_OBJECT, offsetof (struct symbol_value_buffer_local,
default_value) },
{ XD_LO_RESET_NIL, offsetof (struct symbol_value_buffer_local,
current_value), 3 },
{ XD_END }
};
Putting current_value systematically to Qnil? Yeah right. Once the
bug found, it was a Simple Matter Of Programming ;-)
The bugfix is in xemacs-patches.
OG.
PS: Don't worry, it's just that the portable dumper has reached a
level of stability good enough that bugs are at least that perverted.
- 1 participants
- 0 comments
Re: Emacs and the elusive 21.0
23 years, 5 months
Adrian Aichner
Adrian Aichner
>>>>> "Martin" == Martin Buchholz <martin(a)xemacs.org> writes:
>>>>> "DK" == Dhruva KRISHNAMURTHY <Dhruva_KRISHNAMURTHY(a)delmia.com> writes:
DK> For offering to be a Pre-Tester for GNU Emacs - The response I got!!
Martin> I've also been turned down.
Are you kidding?
I wonder what the first f-word stands for in the FSF :-)
DK> The Open Software development is NOT SO OPEN AS IT SHOULD BE!! I now know how
DK> open and accessable XEmacs. I admire the openess of XEmacs development
DK> community.
Martin> Even the XEmacs community is not as open as it should be.
>>>> As far as I know, Emacs 21 isn't in pretest yet (but might be any
>>>> day). Also, there is a closed list of pretesters. Not sure whom to
>>>> ask if you want to become a member.
>>> <gerd(a)gnu.org> - However he's not keen on "accepting" new
>>> contributors untill the next release is out.
Martin> But Gerd is a good guy - the closedness is probably exclusively due to rms.
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org
- 3 participants
- 3 comments
Re: GC crash on 21.2.37 (Was Re: GC crash with 21.2.36 on Solaris 2.7)
23 years, 5 months
Gunnar Evermann
Gunnar Evermann
Hrvoje Niksic <hniksic(a)arsdigita.com> writes:
> Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes:
>
> > > - Lisp_Object handler;
> > > + Lisp_Object handler = Qnil;
> >
> > out of interest, is this always neccessary?
>
> The initialization necessary only because of the newly introduced
> GCPRO on that variable. GCPRO (foo) declares that the Lisp object
> pointed to by &foo is a "root of accessibility", which means that it
> will be marked in the mark phase of GC. If you don't initialize it,
> the GC code will try to dereference random garbage and set the mark
> bit there, leading to a crash.
Yes, that's what I realised after writing the question and meant by
"Hm, I guess it is". We should automatically check whether we always
do this. Maybe in debug_gcpro().
Ray, I have another patch for you. I think this one matches the
symptoms of the crash better than Martin's (no offence). We crash
right after the GCPRO in lock_file() and try to mark_object(0).
Sorry, no ChangeLog, etc. and linenumber might be off. I am in a hurry
right now.
Gunnar
--- filelock.c~ Wed Nov 8 11:20:49 2000
+++ filelock.c Thu Nov 16 13:28:37 2000
＠＠ -313,8 +313,8 ＠＠
register char *lfname, *locker;
lock_info_type lock_info;
struct gcpro gcpro1, gcpro2, gcpro3;
- Lisp_Object old_current_buffer;
- Lisp_Object subject_buf;
+ Lisp_Object old_current_buffer = Qnil;
+ Lisp_Object subject_buf = Qnil;
if (inhibit_clash_detection)
return;
- 3 participants
- 2 comments
Re: Emacs and the elusive 21.0
23 years, 5 months
Adrian Aichner
Adrian Aichner
>>>>> "WP" == William M Perry <wmperry(a)aventail.com> writes:
WP> Adrian Aichner <adrian(a)xemacs.org> writes:
>> >>>>> "Martin" == Martin Buchholz <martin(a)xemacs.org> writes:
>>
>> >>>>> "DK" == Dhruva KRISHNAMURTHY <Dhruva_KRISHNAMURTHY(a)delmia.com> writes:
DK> For offering to be a Pre-Tester for GNU Emacs - The response I got!!
>>
Martin> I've also been turned down.
>>
>> Are you kidding?
WP> I've been on it for ages... stallman habitually tells me how he wishes I
WP> wouldn't work on XEmacs, but I've never been ostracized for it. Strange.
>> I wonder what the first f-word stands for in the FSF :-)
WP> friggin? :)
That's a good one:
Main Entry: frig
Pronunciation: 'frig
Function: intransitive verb
Inflected Form(s): frigged; frig·ging
Etymology: Middle English fryggen to wriggle
Date: 1598
usually vulgar : COPULATE -- sometimes used in
the present participle as a meaningless
intensive
And this is quite funny too:
Main Entry: 1wrig·gle
Pronunciation: 'ri-g&l
Function: verb
Inflected Form(s): wrig·gled; wrig·gling
/-g(&-)li[ng]/ Etymology: Middle English, from
or akin to Middle Low German wriggeln to
wriggle; akin to Old English wrigian to turn --
more at
WRY
Date: 15th century
intransitive senses
1 : to move the body or a bodily part to and fro
with short writhing motions like a worm : SQUIRM
2 : to move or advance by twisting and turning
3 : to extricate or insinuate oneself or reach a
goal as if by wriggling transitive senses
1 : to cause to move in short quick contortions
2 : to introduce, insinuate, or bring into a
state or place by or as if by wriggling
- wrig·gly /-g(&-)lE/ adjective
We demand public access to the sources of that FSF!
I think GNU Emacs should be moved to SourceForge too :-)
Adrian
WP> -bp
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org
- 1 participants
- 0 comments
Re: Audits and vetos [was: Issues outstanding, redux (summary)]
23 years, 5 months
Adrian Aichner
Adrian Aichner
>>>>> "Stephen" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes:
>>>>> "APA" == Adrian Aichner <adrian(a)xemacs.org> writes:
Stephen> o Audit for synchs and feature additions that don't work
Stephen> with Mule (eg, people have patched/intend to patch
Stephen> smtpmail and ps-print in ways that cause data loss and
Stephen> other wastage under Mule)
APA> smtpmail:
APA> Steve, please don't limit yourself to vetoing and auditing.
Stephen> I don't. My message that you cited still has 3.5 days
Stephen> left in my deadline, OK? Getting this right is not an
I didn't mean to pressurize you, but your broad statement above made
people contributing to smtpmail and ps-print* really look bad.
Stephen> easy thing; mail is a bitch, and I'm not a mail
Stephen> specialist. Nor is Mule trivial, at least I know
Stephen> something about that. And I never heard of smtpmail
I sure appreciate that.
Stephen> until Simon's patch the other day, let alone looked at
Stephen> it. Testing it will be time-consuming, as I have never
Stephen> explicitly specified a mailer backend for xemacs before;
Stephen> I'll have to figure out how to do that. Not to mention
Stephen> coming up with a few test cases.
APA> I have offered to patch smtpmail as per your recommendation.
Stephen> Adrian, I don't know when the current version of smtpmail
Stephen> was checked in or by whom, but it is BROKEN. Not after
OK. That statement rehabilitates Simon. Many of your statements
leave a lot room for interpretation.
Stephen> Simon's patch. The one currently being distributed in
Stephen> mail-lib.
Stephen> Any attempt to send non-ISO-8859-1 characters by smtpmail
Stephen> as it stands will turn every single one of them into a
Stephen> tilde, to the best of my knowledge. The fact that we
Stephen> haven't had any bug reports about it leads me to hope
Stephen> that I've analyzed it incorrectly. Still I am unwilling
Stephen> to approve a patch until I have reason to believe it
Stephen> doesn't make things worse than they already are. Adding
Fair enough. It's good to hear you still plan to fix this.
Stephen> features that would attract users to the package is
Stephen> making things worse, unless there are some safeguards put
Stephen> in place to keep it from doing harm.
I completely agree.
Stephen> The patch you proposed to ps-print would do a similar
Stephen> thing for printing from Mule; at least ps-print would
Stephen> merely waste paper.
Which one? See what I mean? Please provide a URL or Message-ID.
I haven't mailed in a ps-print patch recently, AFAIK.
Stephen> The point is not any particular patch; it's just random
Stephen> luck that the two cases I know of right now are these
Stephen> two.
Stephen> But surely there are more of these in the code base by
Stephen> now. I don't review every patch for Mule implications;
Stephen> maybe I should have, and I'll start trying to do more,
Stephen> but EVERYTHING on xemacs-patches is a LOT of traffic.
Stephen> Auditing for this kind of thing is necessary for a
Stephen> release. People will be VERY angry if they lose mail
Stephen> because of this.
No question about that.
APA> ps-print-nomule:
APA> I almost have a patch for ps-print-nomule ready. I am not
APA> qualified to work in the mule version.
Stephen> And it will be reviewed for Mule implications even though
Stephen> it is nominally "non-Mule," and it will be vetoed if it
Stephen> causes problems if invoked from a Mule XEmacs.
OK. Perhaps you can make recommendations how to avoid using
ps-print-nomule under Mule XEmacs.
Stephen> At which point if other reviewers feel that the benefits
Stephen> of the patch to non-Mule users outweigh the problems for
Stephen> Mule, the veto will be overridden. That's the way the
Stephen> process is supposed to work.
Yes. I'll give it a shot.
Best regards,
Adrian
Stephen> --
Stephen> University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Stephen> Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
Stephen> _________________ _________________ _________________ _________________
Stephen> What are those straight lines for? "XEmacs rules."
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org
- 1 participants
- 0 comments
Re: GC crash on 21.2.37 (Was Re: GC crash with 21.2.36 on Solaris 2.7)
23 years, 5 months
Raymond Toy
Raymond Toy
>>>>> "Martin" == Martin Buchholz <martin(a)xemacs.org> writes:
Martin> This patch is a winner!
Martin> Well, actually the code does initialize old_current_buffer, so I
Martin> propose instead this slight improvement:
Is this the patch you want me to apply? Do this instead of your
previous one that initialized handler to Qnil?
Bad news though. The 100% repeatable case I had yesterday isn't
today. I ran the case several times yesterday and it crashed. Now it
doesn't. Yuck. I had to modify the file I was using (real work you
know), and now it's not repeatable.
However, if this is close to the solution, then it should solve some
of the problems I've been having.
Ray
- 2 participants
- 1 comments
Re: GC crash on 21.2.37 (Was Re: GC crash with 21.2.36 on Solaris 2.7)
23 years, 5 months
Gunnar Evermann
Gunnar Evermann
Martin Buchholz <martin(a)xemacs.org> writes:
> >>>>> "GE" == Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes:
>
> GE> I agree with the RETURN_UNGCPRO but don't think any of this is going
> GE> to make a difference. handler should be GCPRO'd by call3().
>
> No!
>
> The old code carefully UNGCPRO'ed, and then used the unprotected
> variables.
yes, but it used them to call call3_check_string which directly calls
call3, which GCPROs all argument and then calls handler.
> I don't know whether the crash here was caused by unprotected handler,
> or by unprotected call3, or even if my patch actually fixes the problem.
I think the patch I just sent to xemacs-beta looks more promising :-)
We should probably apply both.
Gunnar
- 2 participants
- 1 comments
Re: GC crash on 21.2.37 (Was Re: GC crash with 21.2.36 on Solaris 2.7)
23 years, 5 months
Hrvoje Niksic
Hrvoje Niksic
Martin Buchholz <martin(a)xemacs.org> writes:
> No!
>
> The old code carefully UNGCPRO'ed, and then used the unprotected
> variables.
>
> RETURN_UNCGPRO is not just syntactic sugar here. It evaluates the
> call to call3, during which time GCPRO is still in effect, then
> UNGCPROs and returns the result.
Yes, but Gunnat's point is that call3() itself with GCPRO the object
pointed to by &handler. And all its other arguments, for that matter.
Which is, judging from the sources, quite true.
- 1 participants
- 0 comments
Re: Issues outstanding, redux (summary)
23 years, 5 months
Adrian Aichner
Adrian Aichner
>>>>> "Stephen" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes:
Stephen> Reviving this thread in view of active interest in
Stephen> scheduling a public release on both xemacs-beta and
Stephen> xemacs-review.
Stephen> [Is there a Lisp function for getting the archive URL
Stephen> from a message ID? Actually doing the searches by hand
Stephen> is kinda painful (for some reason recently my HTTP
Stephen> connectivity has sucked, I think it's local network
Stephen> mismanagement). If I could just queue them up to be
Stephen> dumped in a buffer it would be cool.]
I suggested making the XEmacs mailing lists searchable for Message ID,
based on the fact that they are contained in HTML comments anyways.
This has never been implemented.
Remember that the archive is a few days behind, it can't currently be
used to refer to recent articles.
HTTP URL IDs would be ideal to keep track of things though.
Stephen> Since there's a lot of stuff here, I suggest that if you
Stephen> have issues to add, can confirm that one has been
Stephen> resolved, or want to say that a particular issue is
Stephen> irrelevant to a near-future release, do it in this
Stephen> thread.
Stephen> If you want to discuss any of the particular points, try
Stephen> to start a new thread (or reply to an existing
Stephen> alternative thread).
Stephen> Gunnar Everman has posted several BTS reports; I guess
Stephen> those should be at least evaluated and presumably fixed
Stephen> before release.
Stephen> Gunnar (if you're watching), do you have a summary handy,
Stephen> or should I go filter the archives?
Stephen> The John A Turner <turner(a)blueskystudios.com> list from
Stephen> <14831.4977.793843.120439(a)denmark.blueskystudios.com>:
Stephen> o the dired customize prob reported here remains:
Stephen> http://www.xemacs.org/list-archives/xemacs-beta/200002/msg00139.html
Stephen> Fixed, per Charles Waldman and Michael Sperber. A package issue,
Stephen> anyway, but dired/efs are too important to the core to ignore.
Stephen> I believe this fix has been applied in the current dired package?
dired is kept externally by Michael Sperber.
The last three updates were these:
1998-12-09 SL Baur <steve(a)altair.xemacs.org>
* Makefile.dired: Remove conflicting install: target.
1998-05-05 SL Baur <steve(a)altair.xemacs.org>
* dired-xemacs.el (dired-install-menubar): Use easy-menu for
adding menus to menubar.
1998-02-17 Michael Sperber [Mr. Preprocessor] <sperber(a)informatik.uni-tuebingen.de>
* diff.el: Region stays for diff-beginning-of-buffer and
diff-end-of-buffer.
Is an XEmacs package which hasn't been updated in two years to be
called "maintained"?
Stephen> o focus being lost after pressing Done in a Customize buffer - I still
Stephen> see the problem on both Irix and win32 - I do use focus-follows-mouse
Stephen> http://www.xemacs.org/list-archives/xemacs-beta/200001/msg00202.html
Stephen> o the weirdness in Motif buttons, both in dialogs and in Customize
Stephen> buffers - best report was this one, which has pics:
Stephen> http://www.xemacs.org/list-archives/xemacs-beta/200010/msg00241.html
Stephen> giacomo boffi <giacomo.boffi(a)polimi.it> in
Stephen> <14832.25010.115179.114817(a)boffi95.stru.polimi.it>
Stephen> o faces bold, italic, bold-italic don't react to size changes
Stephen> Raymond Toy <toy(a)rtp.ericsson.se>:
Stephen> o When fontifying a buffer, the progress bar moves
Stephen> very very slowly and fontification takes forever (>
Stephen> many seconds). However, if I just move the mouse
Stephen> around in the window, the progress bar zips by very
Stephen> quickly, and fontification finishes in less than a
Stephen> second.
Stephen> o A possibly related problem: I start up xemacs and
Stephen> gnus from the command line and have it iconified. It
Stephen> gets stuck somewhere loading up something. As soon
Stephen> as I deiconify it, it zips right along.
Stephen> Raymond Toy's 21.2.3[67] on Solaris/GCC 2.95.2 crashes:
Stephen> <200011072055.PAA22167(a)edgedsp4.ericsson.COM> (and thread)
Stephen> <4nr94dp9lc.fsf_-_(a)rtp.ericsson.se>
Stephen> My own agenda for Mule (not previously published), no particular
Stephen> priority order:
Stephen> o Audit for synchs and feature additions that don't
Stephen> work with Mule (eg, people have patched/intend to
Stephen> patch smtpmail and ps-print in ways that cause data
Stephen> loss and other wastage under Mule)
smtpmail:
Steve, please don't limit yourself to vetoing and auditing.
I have offered to patch smtpmail as per your recommendation.
Further discussion revealed more underlyng problems.
This is the latest status I have and don't plan to do anything further
on the subject:
SJT> From: "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp>
SJT> Subject: Re: smtpmail: auth + starttls support
SJT> To: Simon Josefsson <sj(a)extundo.com>
SJT> Cc: Adrian Aichner <adrian(a)xemacs.org>, Steve Youngs <youngs(a)xemacs.org>,
SJT> xemacs-review(a)xemacs.org
SJT> Date: Tue, 14 Nov 2000 18:47:32 +0900 (JST)
SJT> Message-ID: <14865.2612.169221.665492(a)turnbull.sk.tsukuba.ac.jp>
SJT> References: <iluhf5qd50b.fsf(a)barbar.josefsson.org>
SJT> <un1f8jfef.fsf(a)rapier.ecf.teradyne.com>
SJT> <iluaeb79ynk.fsf(a)barbar.josefsson.org>
SJT> <u4s1f5q47.fsf(a)rapier.ecf.teradyne.com>
SJT> <14860.49082.769703.470071(a)turnbull.sk.tsukuba.ac.jp>
SJT> <u3dgy4w9h.fsf(a)rapier.ecf.teradyne.com>
SJT> <uy9yq3g45.fsf(a)rapier.ecf.teradyne.com>
SJT> <14863.15759.122121.129382(a)turnbull.sk.tsukuba.ac.jp>
SJT> <ilu8zqociq2.fsf(a)barbar.josefsson.org>
SJT> <14863.64831.190240.498205(a)turnbull.sk.tsukuba.ac.jp>
SJT> <iluofzjriuu.fsf(a)barbar.josefsson.org>
SJT> Xref: ZJ75T xemacs-review:1704
SJT>
SJT> >>>>> "Simon" == Simon Josefsson <sj(a)extundo.com> writes:
SJT>
SJT> >> Yuck. This is not good. smtpmail-code-conv-from is defvar'd,
SJT> >> set, or bound somewhere, using a Mule function. That probably
SJT> >> needs to be protected.
SJT>
SJT> Simon> Judging from the variable documentation for
SJT> Simon> smtpmail-code-conv-from is for tiny-mime. Grepping through
SJT> Simon> all Emacs and XEmacs-packages show no hits (except
SJT> Simon> smtpmail), so I guess it's only used by tiny-mime.
SJT>
SJT> OK, I've looked at the code, I couldn't help myself. smtpmail, as is,
SJT> can not be used from Mule at all, except as a backend to a
SJT> full-featured MIME-capable MUA. Using it as the delivery agent for
SJT> plain message-mode or sendmail-mode _will_ destroy your mail if you
SJT> don't use ISO-8859-1 (I am not entirely sure that is safe, but it
SJT> might be).
<lines deleted by Adrian>
SJT> I'll try to get to this by the weekend. In the meantime, I hope
SJT> nobody using Mule uses it.
SJT>
SJT>
SJT> --
SJT> University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
SJT> Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
SJT> _________________ _________________ _________________ _________________
SJT> What are those straight lines for? "XEmacs rules."
ps-print-nomule:
I almost have a patch for ps-print-nomule ready.
I am not qualified to work in the mule version.
Best regards,
Adrian
Stephen> o Fix the autodetection so that only the most common
Stephen> encodings for each environment are autodetected in
Stephen> that environment by default; if there is no language
Stephen> environment set, autodetection is not done. This is
Stephen> a noticable semantic change but at the current pace
Stephen> of release we should do it for the next release and
Stephen> hope most Mule users set language environment.
Stephen> o Partial Windows 12xx support for many values of
Stephen> `xx'.
Stephen> o Windows 12xx graphic glyph support. (Can be done
Stephen> any time.)
Stephen> o (Desirable) Update the fill code, partial synch to
Stephen> FSF 20.7, and fix the kinsoku
Stephen> trailing-whitespace-is-significant bug (FSF still has
Stephen> it). Probably will take time to shake out, though.
>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)arsdigita.com> writes
Stephen> (on xemacs-review):
Hrvoje> I'm also worried by the portable dumping. That part seems
Hrvoje> to have reached the mythical 80%/20% border where it
Hrvoje> _appears_ to be finished, but in reality is far from that.
Hrvoje> (Specifically, there's no alternative for purespace,
Hrvoje> it seems to consume a lot more memory, and
Hrvoje> it seems to be slower.)
Stephen> More pdumper:
>>>>> "Troy" == Troy Noble <troy.noble(a)channelpoint.com> writes in
Stephen> <03E742431696D311BD1B00062938251703DFA5AB(a)cpex1.channelpoint.com>:
Troy> (setq-default ) on an opaque type doesn't work properly
Troy> after the dumper reloads it into memory.
>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)arsdigita.com> writes
Stephen> (on xemacs-review):
Hrvoje> The one good consequence of the core/packages separation
Hrvoje> is that releasing XEmacs is not as hard as it used to be.
Stephen> Are the bad consequences relevant to the issues list, for either
Stephen> fixing or improvement, or is there absolutely nothing that can be done
Stephen> about them without remerging the packages into the core?
Stephen> --
Stephen> University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Stephen> Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
Stephen> _________________ _________________ _________________ _________________
Stephen> What are those straight lines for? "XEmacs rules."
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org
- 3 participants
- 2 comments