Re: 21.5.28: Crash in lucid menubar, XFontsOfFontSet

Ville Skyttä writes: I'm sorry, but it needs to be *exact*. For example, that "only practical difference" is a real big one. GCC bugs/features are very often the underlying cause of this kind of thing (ie, crashes that occur only on one person's system), so that *really* matters. Also what X was compiled with, etc. Well, if that's what it is, please say so, including the options if any used to start XEmacs (and if it doesn't match "^xemacs -vanilla$ they need to go back and try that to confirm it's not affected by something in their personal environment, etc). Oh, so they're using bleeding edge X.org, too? :-( Well, that could be, but as I say this is entirely concealed by the GCC backtrace. The xfontset being NULL is obviously what caused the crash, but why it's NULL, who knows? If the user wants to ship me his environment, machine and all, maybe something can be done, but without a way to reproduce locally, I can't do anything useful. Recent X is downright irresponsible code, unfortunately. For years XFree86 and X.org have been accepting code that breaks API promises right and left. Keymapping stops working, "nonblocking" APIs[1] can block six or seven different ways, character encodings forbidden *specifically* by one part of the standard *as specifically amended* by the project are implemented as new APIs, .... I have some sympathy for why they do this stuff, but from the user's point of view, the bottom line is I'm not willing to fight crashes that clearly involve X unless I can watch the crash as it happens in the debugger. Footnotes: [1] Ie, APIs introduced for the specific purpose of not blocking! _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta