21.5.28: Crash in lucid menubar, XFontsOfFontSet
Ville Skyttä
scop at xemacs.org
Sun Mar 15 16:13:42 EDT 2009
On Tuesday 10 March 2009, Ville Skyttä wrote:
> On Tuesday 10 March 2009, Jerry James wrote:
> > On Mon, Mar 9, 2009 at 2:14 PM, Ville Skyttä <scop at xemacs.org> wrote:
> > > 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.
> >
> > Actually, I do run Fedora Rawhide inside a virtual machine on my
> > Fedora 10 desktop. Sorry, I've only been half paying attention to the
> > list. Is there something I need to check?
>
> If you're interested, help would be welcome with this:
> https://bugzilla.redhat.com/show_bug.cgi?id=489145
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.
More information about the XEmacs-Beta
mailing list