Bug 489145

Possibly the same issue as bug 478370

Could you attach the output of "xlsfonts"?

Created attachment 334449 [details]
requested xlsfonts output

This is requested info.

Yes, this is dup of bug 478370, which did not mention "core dump", the
keyword I was looking for.

*** This bug has been marked as a duplicate of bug 478370 ***

Let's track this issue here, the original report in #478370 might not be the same issue.

Could you try out 21.5.28-12.fc11 from http://koji.fedoraproject.org/koji/taskinfo?taskID=1230151 and let me know how it looks?  It's just a workaround build to disables xfontset support in menus altogether.

(In reply to comment #5)
> Let's track this issue here, the original report in #478370 might not be the
> same issue.
> 
> Could you try out 21.5.28-12.fc11 from
> http://koji.fedoraproject.org/koji/taskinfo?taskID=1230151 and let me know how
> it looks?  It's just a workaround build to disables xfontset support in menus
> altogether.  

Installed xemacs{,-common} here from the above. Now xemacs starts in graphical mode, but says:

  $ xemacs
  Warning: Missing charsets in String to FontSet conversion
  Warning: Cannot convert string "-*-helvetica-bold-r-*-*-*-120-*-*-*-*-iso10646-1, 				-*-helvetica-bold-r-*-*-*-120-*-*-*-*-iso8859-*, 				*" to type FontSet
  Warning: Missing charsets in String to FontSet conversion
  Warning: Unable to load any usable fontset
  Warning: Missing charsets in String to FontSet conversion
  Warning: Unable to load any usable fontset

Created attachment 334453 [details]
xlsfonts output for me

This is x86_64

I installed xemacs* from Comment#5, 
    [timliim@formosa ~]$ rpm -qa | grep xemacs
    xemacs-21.5.28-12.fc11.x86_64
    xemacs-nox-21.5.28-12.fc11.x86_64
    xemacs-packages-base-20090217-1.fc11.noarch
    xemacs-devel-21.5.28-12.fc11.x86_64
    xemacs-el-21.5.28-12.fc11.x86_64
    xemacs-common-21.5.28-12.fc11.x86_64
    xemacs-debuginfo-21.5.28-12.fc11.x86_64

Got same result as Horst did in Comment #6:
  - started in X mode
  - same warning msg 

With i586 rpm on 32-bit os I got the same result: 
  - core dump with 21.5.28-11.fc11.i586
  - -21.5.28-12 started in X mode, asme warning msg.

Just realized that xemacs-21.5.28-11.fc11.x86_64 started ok in GUI
in a fresh F11 installation; the core dump developed after updating 
to latest rawhide.  I'm in the process of isolating which updates
brings the core issue.

(In reply to comment #6)
> (In reply to comment #5)

[...]

BTW, a *Warnings* buffers opens in xemacs, containing:
  
  (1) (xintl/error) Can't initialize XIM: Can't get fontset resource for Input Method

Now trying to get some work (mostly LaTeX) done...

Thanks in advance.  Being able to start up is a decent improvement for now
though ;)

Could you try the following commands and let me know if they output something
that looks like a sane font matching the requested pattern being found?

xlsfonts -fn "-*-helvetica-bold-r-*-*-*-120-*-*-*-*-iso10646-1"
xlsfonts -fn "-*-helvetica-bold-r-*-*-*-120-*-*-*-*-iso8859-*"
xlsfonts -fn "*" # no need to post the output of this, it should output
everything

Also, do these commands show the requested font without warnings on the
console?

xfd -fn "-*-helvetica-bold-r-*-*-*-120-*-*-*-*-iso10646-1"
xfd -fn "-*-helvetica-bold-r-*-*-*-120-*-*-*-*-iso8859-*"

Does xfontsel start up without warnings on the console?  What about "display
/path/to/some/image" (ImageMagick) or "gm display /path/to/some/image"
(GraphicsMagick)?  What about xfig?

Does /etc/X11/xorg.conf have anything related to fonts or font paths?

What's your $LANG set to?  Does it make any difference if you start xemacs with
"LANG=C xemacs"?

Also, do the warnings (or the crash if you still have -11.fc11 around) occur if you run xemacs with the -vanilla option?

(In reply to comment #11)
> Thanks in advance.  Being able to start up is a decent improvement for now
> though ;)

Nodz _very_ vigorously.

> Could you try the following commands and let me know if they output something
> that looks like a sane font matching the requested pattern being found?

> xlsfonts -fn "-*-helvetica-bold-r-*-*-*-120-*-*-*-*-iso10646-1"

-adobe-helvetica-bold-r-normal--12-120-75-75-p-70-iso10646-1
-adobe-helvetica-bold-r-normal--17-120-100-100-p-92-iso10646-1

> xlsfonts -fn "-*-helvetica-bold-r-*-*-*-120-*-*-*-*-iso8859-*"

-adobe-helvetica-bold-r-normal--12-120-75-75-p-70-iso8859-1
-adobe-helvetica-bold-r-normal--17-120-100-100-p-92-iso8859-1

> xlsfonts -fn "*" # no need to post the output of this, it should output
> everything

1891 lines, just like xlsfonts by itself.

> Also, do these commands show the requested font without warnings on the
> console?
> 
> xfd -fn "-*-helvetica-bold-r-*-*-*-120-*-*-*-*-iso10646-1"
> xfd -fn "-*-helvetica-bold-r-*-*-*-120-*-*-*-*-iso8859-*"

Both open a new window showing the characters for the font, no output in the gnome-terminal where I launch them.

> Does xfontsel start up without warnings on the console?  

It says:

  Warning: Missing charsets in String to FontSet conversion
  Warning: Unable to load any usable fontset

A window saying 2347 names match opens.

>                                                         What about "display
> /path/to/some/image" (ImageMagick)

  $ display organigrama.png

is silent, shows the file just fine.

>                                    or "gm display /path/to/some/image"
> (GraphicsMagick)?

  $ gm display tick.png

is silent, shows the file just fine.

>                    What about xfig?

  $ xfig suf.fig

is silent, shows suf.fig fine.

> Does /etc/X11/xorg.conf have anything related to fonts or font paths?

No file /etc/X11/xorg.conf here, hasn't been for a while.

> What's your $LANG set to?

en_US.UTF-8

>                            Does it make any difference if you start xemacs with
> "LANG=C xemacs"?  

Silent, no *Warning* buffer

(In reply to comment #12)
> Also, do the warnings (or the crash if you still have -11.fc11 around) occur if
> you run xemacs with the -vanilla option?  

  $ xemacs -vanilla
  Warning: Missing charsets in String to FontSet conversion
  Warning: Cannot convert string "-*-helvetica-bold-r-*-*-*-120-*-*-*-*-iso10646-1, 				-*-helvetica-bold-r-*-*-*-120-*-*-*-*-iso8859-*, 				*" to type FontSet
  Warning: Missing charsets in String to FontSet conversion
  Warning: Unable to load any usable fontset
  Warning: Missing charsets in String to FontSet conversion
  Warning: Unable to load any usable fontset

A message shows up in the input area of xemacs:

  Error: Can't initialize XIM: Can't get fontset resource for Input Method

Sorry, I don't have -11 anymore. I could install it, if really important/useful.

(In reply to comment #12)
> Also, do the warnings (or the crash if you still have -11.fc11
> around) occur if you run xemacs with the -vanilla option?
Yes, with -vanilla -11.fc11 still core dumps as it did without
-vanilla.

Re: Comment #9
I don't know how/why libX11 causes crash of xemacs, but it does.  I
installed F11 x64 fresh, with minimum packages (~1000 rpms) , then did
the following:
    yum update -y rpm
    yum update -y yum
    yum install -y compface neXtaw xorg-x11-fonts-ISO8859-1-100dpi 
	    xorg-x11-fonts-ISO8859-1-75dpi
    rpm -i xemacs-*  
	# I obtained 
	    xemacs-21.5.28-11.fc11.x86_64.rpm
	    xemacs-common-21.5.28-11.fc11.x86_64.rpm
	    xemacs-packages-base-20090217-1.fc11.noarch.rpm
	  from
	    # xemacs-21.5.28-11.fc11
	    http://koji.fedoraproject.org/koji/buildinfo?buildID=90553  
	    # xemacs-packages-base-20090217-1.fc11
	    http://koji.fedoraproject.org/koji/buildinfo?buildID=93167

At this point, I started "xemacs &" and it started fine in GUI, with
libX11-1.1.99.2-2.fc11.x86_64.

After doing "yum update libX11" to libX11-1.2-3.fc11.x86_64, I got
the signature xemacs core dump.

good: libX11-1.1.99.2-2.fc11.x86_64
bad:  libX11-1.2-3.fc11.x86_64

Not sure if this helps your debugging, but it's another view.

Thanks for all the info.  When you say 'I started "xemacs &" and it started fine in GUI', does that mean that it didn't even output those string to fontset warnings?

On the terminal where I start xemacs:
    [timliim@yam ~]$ xemacs 
    Warning: Missing charsets in String to FontSet conversion
Just one line warning, instead of the many lines in -12.
xemacs start in GUI fine, _no_ Warning buffer.

Could it be a build problem?  Here is my speculation:
- for ease of discussion,
  #1 = xemacs-21.5.28-11.fc11
  #2 = libX11-1.1.99.2-2.fc11.x86_64 (good  libx11)
  #3 = libX11-1.2-3.fc11.x86_64      ("bad" libX11)

- I think: it is _not_ a xemacs code issue, because #1
  runs fine with #2, but core dumps with #3, with 
  the same binary for #1, ie. no code change in #1.

- I guess: #1 was compiled against #2, so #1 ran 
  fine with #2.

- I guess: between #2, #3 there are some header changes, 
  eg. some struct may change its size, some functions may change
  its argument list, some class may have more/less methods or
  data members.  This guess is based on
      #2 = 1.1.xx
      #3 = 1.2.xx

- if #2, #3 has header change, a binary (eg. #1) compiled against
  #2 is likely to core dump with #3.

- to verify this speculation, we can build #1 against #3.

That's possible, although it can also be some other change in libX11 behavior that triggers the crash and isn't affected by a rebuild.  Anyway, a scratch rebuild of -11 is available at http://koji.fedoraproject.org/koji/taskinfo?taskID=1238296, please try it out.

Also, please test if having xorg-x11-fonts-misc installed or not makes any difference wrt. warning messages on the console and/or crash issues with libX11 1.2.x installed (preferably with both -11.fc11 and -12.fc11 xemacs builds).  Having it installed gets rid of the warnings on F-9 and reportedly F-10.

Ville,
I went to the link in Comment #20, but saw only src.rpm, no binaries.
Is this correct?

No, it's just the "build's name" that has src.rpm on it.  Click one of them matching your architecture, then scroll down to the "Output" section on the following page and you'll see the binaries.

Re: Comment #22
Got.  Thanks.  I missed it the first time.

Re: Comment #20
1. -11.rebuild from Comment #20 behaves the same as -11,
   i.e., both worked fine with libX11-1.1, both cored
   with libx11-1.2.
   My speculation in #19 is not useful, even though the
   observation still holds true (libX11 1.2 breaks 
   xemacs-11).

2.           w/o font-misc     with font-misc
   xemacs-11     *3               no *3
   xemacs-12     *3               no *3

    *3 = on terminal where xemacs started,
         Warning: Missing charsets in String to 
	 FontSet conversion

    With this observation, I believe x-x-fonts-misc 
    is the fix to the "missing charsets" msg.
    Also I did not see any "*Warning*" buffer in xemacs.

Re: Comment #20
> Having it installed gets rid of the warnings on F-9 and reportedly
> F-10.
Yes, I observed the same in F10: 
  - without xorg-x11-fonts-misc, saw warning msg on terminal:
        Warning: Missing charsets in String to 
        FontSet conversion
  - with x-x-f-m, said warning msg is gone.

xlwmenu.c:3125
3125      int fontcount = XFontsOfFontSet(mw->menu.font_set, &fontstruct_list,
(gdb) p mw->menu.font_set
$3 = (XFontSet) 0x0
Where do we get font_set?

(In reply to comment #24)
> Re: Comment #20
> > Having it installed gets rid of the warnings on F-9 and reportedly
> > F-10.
> Yes, I observed the same in F10: 
>   - without xorg-x11-fonts-misc, saw warning msg on terminal:
>         Warning: Missing charsets in String to 
>         FontSet conversion
>   - with x-x-f-m, said warning msg is gone.  

Here x86_64, rawhide, xorg-x11-fonts-misc-7.2-8.fc11.noarch, installed Fri 27 Feb 2009 11:50:38 AM CLST (AFAIR it was installed all over this time); libX11-1.2-3.fc11, installed Sun 01 Mar 2009 01:16:05 AM CLST. xemacs did crash at -11, works at -12. Complains about missing fonts all the same.

Here is what I have found so far:

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.

Fedora made all these debugging much easier for non-maintenaners,
which I am happy to report.  Here is what I did to debug:
  1. downloaded the src.rpm file:
        yumdownloader --source libXt
  2. install:
        sudo yum install rpm-build
        rpm -i libXt*.src.rpm
  3. compile:
        export CFLAGS=-g
        export CXXFLAGS=-g
        cd ~/rpmbuild
        rpmbuild -bb SPEC/libXt.spec
  4. install:
        sudo rpm -i ~/rpmbuild/RPMS/i386/libXt-xxx.rpm
Then I can do source debugging on libXt.  Same for libX11, xemacs.

Re: Comment #27 item #6
Need to remove both:
    cjkuni-uming-fonts-0.2.20080216.1-21.fc11.noarch
    cjkuni-fonts-common-0.2.20080216.1-21.fc11.noarch

Tim, thanks a lot for your efforts.  Actually getting set up for debugging is much easier than what you went through: no need to rebuild anything, you can debug the original binaries.  Just enable the appropriate -debuginfo repositories in /etc/yum.repos.d/*.repo and do eg "yum install libXt-debuginfo" etc.  Or do "debuginfo-install libXt" etc if you have yum-utils installed; this one pulls in a "dependency chain" of -debuginfo packages.

libX11 and cjkuni-fonts maintainers, any comments to comment 27?

Re: Comment #29 -debuginfo rpm
Now I recalled why I jumped thru all the hoops of building from
src.rpm.  The -debuginfo rpm works and is easy to install.  The
only problem is they are compiled with optimization on, so
1. when I need to examine variables, often it is "value optimized
   out," so I don't know the value.
2. in gdb when I do single step, the execution sequence jumps up 
   and down, a sign of optimized code, and I got lost easily.
That is -debuginfo is good for high-level debug, but in this case
I need to examine the details.  Build my own rpm without
optimization makes debugging much easier.

This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

I've also run into this Missing Charsets error, and I poked around and discovered an old package xorg-x11-fonts-truetype-7.2-3.fc8.noarch installed on my fedora 11 system.  (I've upgraded 8 -> 10 -> 11.)  I removed that package, made sure to have xorg-x11-fonts-misc, ran 'xset fp rehash', and now the error message seems to be gone.

This did keep some parts of xemacs from working -- I had trouble with psvn for example.  And xfontsel gave me the same error before I made the above changes.

Maybe there was something in the 8->9 upgrade system that would have removed this package had I not skipped that step?  Oh well.

"package-cleanup --orphans" (in yum-utils) shows such leftovers.

BTW, I have none of those around here, but I'm stuck at xemacs-21.5.28-12.fc11.x86_64, as 21.5.29-1.fc12 breaks auctex (see BZ 512623). In any case, it complains just the same.

Note that this is now rawhide (not F 11 anymore). Anybody change this? Open a new ticket as this is not a crash anymore?

xemacs-21.5.29-2.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/xemacs-21.5.29-2.fc11

xemacs-21.5.29-2.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update xemacs'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-8993

No more core dump observed.  Thanks!  I'll close this bug.

xemacs-21.5.29-2.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.