Re: 21.4.2 mwheel.el woes

Ben> can you get a c backtrace? Reproducing the crash again, I notice the following: [3]- User defined signal 1 ./xemacs I attached to the process with gdb, and as soon as I caused a sound event, XEmacs caught a SIGUSR1. #0 0x40498897 in __libc_pause () from /lib/i686/libc.so.6 #1 0x40360a20 in esd_open_sound (host=0x0) at esdlib.c:691 #2 0x40360b11 in esd_play_stream (format=4112, rate=8000, host=0x0, name=0x81ad040 "xemacs") at esdlib.c:740 #3 0x080c8fb7 in esd_play_sound_data (data=0xbfffdb80 "RIFF\"\002", length=554, vol=50) at esd.c:102 #4 0x08158a54 in Fplay_sound (sound=137128548, volume=136371572, device=138417888) at sound.c:337 #5 0x08158f84 in Fding (arg=136371572, sound=137128548, device=136371572) at sound.c:413 #6 0x080ae97f in Ffuncall (nargs=3, args=0xbfffdf14) at eval.c:3528 So esd does evil things with SIGUSR1, and I think it's interfering with XEmacs's handling of SIGUSR1. In xemacs-21.4.2/src/signal.c: static void handle_signal_if_fatal (int signo) { if (signal (signo, fatal_error_signal) == SIG_IGN) signal (signo, SIG_IGN); } and #ifdef SIGUSR1 handle_signal_if_fatal (SIGUSR1); /* POSIX */ #endif I assume the /* POSIX */ comment means that SIGUSR1 is a POSIX signal as opposed to an ANSI signal, not that the signal is handled with POSIX sementics. So there's a possibility that in between the 2 calls to signal, another signal could arrive, and since the signal is reset to default behavior, the unignored SIGUSR1 causes a crash. Would using the POSIX signal functions (sigaction and friends) help here? Isaac