Re: [Bug: 21.5-b28] Crash when closing xemacs via window manager

Due to lack of time, bright ideas, and access to X documentation, I'm going to have to postpone most work on this until I get back to Japan (nominally August 21, but what with the quarter starting on September 1, more likely early September). Anybody with suggestions, please pipe up! I can probably review patches, if anybody gets that far. Raymond Toy writes: This backtrace comes from a crash, right? But it doesn't look like one, usually frame #0 in a crash backtrace is an abort or signal handler in libc. If it is a crash, it's crashing in a completely different place, wich could mean (a) two crashes or (b) one or both of the optimizations was seriously misleading us about where the crash was actually happening. This looks like Xt is recursively calling itself somehow. I don't understand why that should happen, either. The only thing I can think of, again, is that the window manager has deleted a window out from under us, and we don't find out until we've spewed a ton of X protocol out to the server. But I would think Xlib would handle that for us, in cooperation with the Xserver. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta