Ville Skyttä writes:
This isn't the exact one but the only practical difference
be that the one the OP is using was compiled with gcc 4.4.
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.
I'm afraid that'd be more or less "start XEmacs".
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).
Note that I don't have access to an environment where this could
reproduced either, but AFAICT there has been some changes related
to "legacy fonts" handling in bleeding edge X.org (some fonts
"embedded" in the server or something like that).
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 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
 Ie, APIs introduced for the specific purpose of not blocking!
XEmacs-Beta mailing list