Re: 21.4.8 garbage collection crash

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; wrote: OK, I just ran XEmacs 21.4.8 under purify, with and without Mule, running gnus, and there's nothing that clearly stands out as a culprit for these crashes. This is under HP-UX 11.11i and with Motif, and so it could be a linux or xaw3d problem. [ It did find a minor Motif buglet, although that isn't causing the crash. I'll submit a patch in a day or two. ] One possible issue is that, with Mule, XRegisterIMInstantiateCallback() doesn't seem to like being passed NULL arguments for res_name/res_class (I'm guessing, here). The NULL pointers get passed to _XimOpenIM(), and they get dereferenced: =============================================================================== **** Purify instrumented ./temacs (pid 29657) **** NPR: Null pointer read: * This is occurring while in: strncpy [rtlib.o] _XimMakeImName [libX11.3] _XimOpenIM [libX11.3] _XimRegisterIMInstantiateCallback [libX11.3] XRegisterIMInstantiateCallback [libX11.3] XIM_init_device [input-method-xlib.c:254] x_init_device [device-x.c:767] Fmake_device [device.c:591] Ffuncall [eval.c:3528] execute_optimized_program [bytecode.c:746] funcall_compiled_function [bytecode.c:515] Ffuncall [eval.c:3563] execute_optimized_program [bytecode.c:746] funcall_compiled_function [bytecode.c:515] Ffuncall [eval.c:3563] execute_optimized_program [bytecode.c:746] funcall_compiled_function [bytecode.c:515] Feval [eval.c:3388] condition_case_1 [eval.c:1651] condition_case_3 [eval.c:1729] execute_rare_opcode [bytecode.c:1271] execute_optimized_program [bytecode.c:656] funcall_compiled_function [bytecode.c:515] Feval [eval.c:3388] condition_case_1 [eval.c:1651] top_level_1 [cmdloop.c:206] internal_catch [eval.c:1317] initial_command_loop [cmdloop.c:285] xemacs_21_4_8_hppa2_0w_hp_hpux11_11 [emacs.c:2353] main [emacs.c:2782] _start [libc.2] $START$ [crt0.o] * Reading 1 byte from 0x0 =============================================================================== I have a few more purify error stack traces that look similar (they're all related to XRegisterIMInstantiateCallback() or XimOpenIM()). I'm a bit confused, as under Linux, dereferencing a NULL pointer causes a core dump, and we're not seeing it. Note that the above is occurring as the initial top-level frame is being created/displayed, and is not occurring during gnus usage. This might be an HP-UX-specific issue, however. -- Darryl Okahata darrylo(a)soco.agilent.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day.