On Sunday 08 March 2009, Stephen J. Turnbull wrote: No, no Xft. Pointer to it was already in my previous message: http://calypso.tux.org/pipermail/xemacs-beta/2009-February/015773.html This isn't the exact one but the only practical difference should be that the one the OP is using was compiled with gcc 4.4. I'm afraid that'd be more or less "start XEmacs". Note that I don't have access to an environment where this could be 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). _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

On Monday 09 March 2009, Stephen J. Turnbull wrote: Here's why I think it doesn't really matter in this case, and there are a lot of other similar ones as well although this one (Fedora development) is about as bleeding edge/extreme as it gets: There's no way a simple gcc version string can exactly describe the compiler used. For example the Fedora development gcc 4.4 is an upstream not-even-pre-release-I-think snapshot and has tens of patches applied on top of it (Fedora gcc maintainer is also a gcc upstream dev, duh). http://cvs.fedoraproject.org/viewvc/devel/gcc/ Ditto X: http://cvs.fedoraproject.org/viewvc/devel/xorg-x11-server/ Nobody here is going to even try to install the exact same environment the OP has. Even people who for some reason run Fedora development (I don't, and unless Jerry does, I bet nobody else here does) would only try with their environment du jour. Someone on entirely different distro/OS might have a different gcc 4.4 snapshot available and could be interested enough to try out with it, ditto X, and report whether they can reproduce or not. Or someone might have a clue what's up just by looking at the stack trace or could remember seeing a similar crash sometime in an entirely different environment, or remember/know/have a clue that the bug/misconfiguration/$something is not in XEmacs but somewhere else and of the kind that it makes no sense to even try working around it in XEmacs. I don't expect anything more. And FWIW, this isn't something that occurs only on one person's system. There's at least two of them, and given what I guess is the popularity of XEmacs in Fedora at the moment, I think with two active bug reporters who run into the exact same issue at the same time, it can be fairly safely assumed that it crashes for everyone running Fedora development currently. (Well, not any more, I disabled XFontSet support in the latest build, currently only string to fontset conversion warnings remain.) I thought that was obvious from the original bug report. This one I missed, and have asked now. Come on, this is just silly. Nobody is demanding you (or anyone for that matter) to do anything. I just forwarded a bug report. You could just have left it at your previous reply (and can still leave it at this) and maybe someone else would have looked into it, maybe not. Starting ranting about gcc and/or X instability or (even jokingly) asking physical machines to be shipped around just diverts people's attention elsewhere. At least it does that for me (not that it matters much in my case, I'm not qualified to really do much more than forward bug reports and act as a patch monkey in these parts of XEmacs anyway). _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

On Tuesday 10 March 2009, Jerry James wrote: If you're interested, help would be welcome with this: https://bugzilla.redhat.com/show_bug.cgi?id=489145 xemacs-21.5.28-11.fc11 reportedly crashes at startup in GUI mode. xemacs-21.5.28-12.fc11 doesn't but outputs string to fontset conversion warnings. The only difference between -11.fc11 and -12.fc11 is that the former is built --with-xfs, ther latter not as an immediate band-aid to get a startable XEmacs in the hands of Rawhide users. (-12.fc11 can be rebuilt with XFontSet support using "--with xfs" rpmbuild/mock option.) Some info later received in the bug indicates that at least some of this might be an issue in or caused by the newly introduced libX11 1.2. Thanks in advance! _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

On Tuesday 10 March 2009, Ville Skyttä wrote: OP posted more useful looking information in comment 27 (https://bugzilla.redhat.com/show_bug.cgi?id=489145#c27). See the "xemacs could be more defensive" suggestion near the bottom, is this something we'd like to have in XEmacs? ---- Summary: This problem occurs when we have libX11-1.2-3.fc11 cjkuni-uming-fonts-0.2.20080216.1-21.fc11.noarch With either one missing, xemacs-21.5.28-11.fc11 is a happy capmer and no core dump. xemacs -11 cores because libX11-1.2 includes this font -misc-ar pl ukai cn-medium-r-normal--0-0-0-0-c-0-iso8859-13 which is missing its "font_set->info". libX11-1.1 does not load said rogue font (into its whatever list), thus no problem. 1. when core dump occurs, it's because mw->menu.font_set is 0: xlwmenu.c:3125 3125 int fontcount = XFontsOfFontSet(mw->menu.font_set, &fontstruct_list, (gdb) p mw->menu.font_set $3 = (XFontSet) 0x0 2. where does mw->menu.font_set come from? #0 extract_font_extents xlwmenu.c:3125 #1 XlwMenuInitialize xlwmenu.c:3256 #2 CallInitialize Create.c:219 (libXt.rpm) #3 xtCreate Create.c:409 In Create.c of libXt, 357 widget = xtWidgetAlloc(widget_class, ... 358 name, args, num_args, ...) # ^^ at this point mw->menu.font_set is initialized to 0. 384 cache_refs = _XtGetResources(widget, args, num_args, # ^^ in good case, this line init mw->menu.font_set to something. # in bad case, mw->menu.font_set remains 0 after line 384. 3. where does _XtGetResources at Create.c:384 get data from? #0 XCreateFontSet FSWrap.c:185 (libX11.rpm) #1 XtCvtStringToFontSet Converters.c:973 #2 CallConverter Convert.c:808 #3 _XtConvert Convert.c:897 #4 GetResources Resources.c:848 #5 _XtGetResources Resources.c:1053 #6 xtCreate Create.c:384 The related lines in #0 are 185 if ((oc = XCreateOC(om, ..., NULL))) { 186 list = &oc->core.missing_list; 187 oc->core.om_automatic = True; 188 } else 189 list = &om->core.required_charset; In good case, XCreateOC return non-zero; In bad case, XCreateOC return 0. BTW, XtDisplayStringConversionWarning (Converters.c:227) is the one emits this msg, when #0 XCreateFontSet return 0: Warning: Cannot convert string "xxx" to type FontSet 227 XtAppWarningMsg(app, 228 XtNconversionError,"string",XtCXtToolkitError, 229 "Cannot convert string \"%s\" to type %s", 230 params,&num_params); 4. What happened in XCreateOC? #0 load_font_info omGeneric.c:339 #1 create_fontset omGeneric.c:1377 #2 create_oc omGeneric.c:1679 #3 XCreateOC OCWrap.c:53 #4 XCreateFontSet FSWrap.c:185 (libX11.rpm) In #0 load_font_info (omGeneric.c:339), we have 332 for ( ; num-- > 0; font_set++) { 337 fn_list = XListFontsWithInfo(dpy, font_set->font_name, ..., 338 &font_set->info); 339 if (font_set->info == NULL) 340 return False; 344 } In good case, we have 7 fonts, all went well. ***************************************************************** In bad case, we have 17 fonts, one rogue font failed line 339, thus all the mayhem. ***************************************************************** 5. What are the 7 or 17 fonts? 7 fonts from libX11-1.1 in F11 (good case. F10 also returns 7 fonts.) 0 -adobe-helvetica-bold-r-normal--12-120-75-75-p-70-iso8859-1 1 -adobe-helvetica-bold-r-normal--12-120-75-75-p-70-iso8859-1 2 -jis-fixed-medium-r-normal--16-110-100-100-c-160-jisx0208.1983-0 3 -daewoo-gothic-medium-r-normal--16-120-100-100-c-160-ksc5601.1987-0 4 -isas-fangsong ti-medium-r-normal--16-160-72-72-c-160-gb2312.1980-0 5 -misc-fixed-medium-r-normal--14-130-75-75-c-70-jisx0201.1976-0 6 -arabic-newspaper-medium-r-normal--32-246-100-100-p-137-iso10646-1 17 fonts from libX11-1.2 in F11 (bad case) 0 -adobe-helvetica-bold-r-normal--12-120-75-75-p-70-iso8859-1 1 -adobe-helvetica-bold-r-normal--12-120-75-75-p-70-iso8859-1 2 -misc-fixed-bold-r-normal--13-120-75-75-c-70-iso8859-2 3 -urw-century schoolbook l-bold-i-normal--0-0-0-0-p-0-iso8859-3 4 -urw-century schoolbook l-bold-i-normal--0-0-0-0-p-0-iso8859-4 5 -misc-fixed-bold-r-normal--13-120-75-75-c-70-iso8859-5 6 -misc-fixed-medium-r-normal--6-60-75-75-c-40-koi8-r 7 -misc-fixed-bold-r-normal--13-120-75-75-c-70-iso8859-7 8 -misc-fixed-bold-r-normal--13-120-75-75-c-70-iso8859-9 culprit ==>9 -misc-ar pl ukai cn-medium-r-normal--0-0-0-0-c-0-iso8859-13<== 10 -misc-fixed-bold-r-normal--13-120-75-75-c-70-iso8859-14 11 -misc-fixed-bold-r-normal--13-120-75-75-c-70-iso8859-15 12 -jis-fixed-medium-r-normal--16-110-100-100-c-160-jisx0208.1983-0 13 -daewoo-gothic-medium-r-normal--16-120-100-100-c-160-ksc5601.1987-0 14 -isas-fangsong ti-medium-r-normal--16-160-72-72-c-160-gb2312.1980-0 15 -misc-fixed-medium-r-normal--14-130-75-75-c-70-jisx0201.1976-0 16 -arabic-newspaper-medium-r-normal--32-246-100-100-p-137-iso10646-1 The culprit is "-misc-ar pl ukai cn-medium-r-normal--0-0-0-0-c-0-iso8859-13" which failed the "font_set->info != NULL" test. 6. easiest workaround: rpm -e cjkuni-uming-fonts-0.2.20080216.1-21.fc11.noarch This font is installed in F11 alpha by default. You can safely remove it if you don't use Asian fonts. I don't need it; I use Romanized Taiwanese writting system (MLT Modern Literal Taiwanese http://taigie.taioaan.org/english/mtl.html). 7. some possibilities 7.1 See #1 above. xemacs could be more defensive, checking mw->menu.font_set != 0 at xlwmenu.c:3125. 3125 ... XFontsOfFontSet(mw->menu.font_set, ... 7.2 See #4 above. In libX11, omGeneric.c:339, load_font_info returns false for one single rogue font that has font_set->info missing, even though all other fonts are good. Do we have to die because one font is bad? Can we remove bad font from whatever list? If we want to die because of a bad font, at least announce its name. In this case we don't even know the bad font's name from stderr. 7.3 See #5 above. Looks like libX11-1.2 adds a few new fonts for whatever purpose. Is it possible to develop a check for sanity of fonts before adding them? I made these observation on two separate F11-alpha i386 hosts. Can someone please confirm these findings are valid. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Ville Skyttä writes: What you've explained is why it's hard to characterize. It still matters, and bug reports should at least state "The auto-generated report lies about the build environment because I don't have access to it, but the following information is correct: ...". That's OK. If their environment is different and they can/can't reproduce, that tells us something important. If an XEmacs dev with any environment *can* reproduce, then we've won. The closer the environment, the more likely we are to reproduce. Then there are two people who can provide the information I requested! Maybe it is, but given the demands on my time (and the general scarcity of XEmacs developer time) I'm going to offload as much effort on reporters as possible. The alternative is "file and forget," which I'd rather avoid. (NB. I do most of my XEmacs work from home over SSH in a TTY gnuclient. I can't click-through-to-bug-report, it requires mousing around and an application switch.) Why do you think so? That is the requirement for effective debugging until somebody who is an XEmacs contributor willing to debug can reproduce. Nor is it technically impractical: he can ship it to me virtually via SSH. I have never done that, but I believe Martin has debugged a number of problems that way. But I *want* to do something. This is a crash, and you say it's common on Fedora, at least in the development version(s). Would it be preferable simply to put it in terms that "without this information I will leave it to someone else to debug"? That doesn't seem very user-friendly to me. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta