Bug 210718

Created attachment 138462 [details]
tail of 'strace' output

Actually a segfault described at the beginning of this report can be
caused in a simpler way.  Names start texdoctk, click "Search", click
"Quit", exit with a "Segmentation fault" message.

Looking at results of strace it looks that this segfault is caused by
munmap() on a cache for /usr/share/fonts/japanese/misc.  Indeed, after
a removal of an owner of this directory, i.e.
fonts-japanese-0.20050222-11.1.1 package, using "Search" in texdoctk
is not causing these segfaults anymore.  Restore fonts-japanese and
segfaults are back.

OTOH uninstalling fonts-japanese does not change a thing if you will
try to open texdoctk on a remote display.  It still bombs.  It is possible
that the problem is really in 'fontconfig' libraries; or maybe something
needs to be adjusted in 'TkpDeleteFont()' interfaces?

After installing perl-Tk-debuginfo and fontconfig-debuginfo I see the
following when running 'gdb --args perl /usr/bin/texdoctk' with
a display on remote:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 46912496218624 (LWP 5911)]
0x000000367e016aaa in FcCompare (pat=0xcc73e0, fnt=0x2aaaab9e5078,
    value=0xd28400, result=0x7fffe4ca3d78) at fcmatch.c:392
392         while (i1 < pat->num && i2 < fnt->num)
(gdb) bt
#0  0x000000367e016aaa in FcCompare (pat=0xcc73e0, fnt=0x2aaaab9e5078,
    value=0xd28400, result=0x7fffe4ca3d78) at fcmatch.c:392
#1  0x000000367e016ef4 in IA__FcFontSetSort (config=<value optimized out>,
    sets=<value optimized out>, nsets=1, p=0xcc73e0, trim=1,
    csp=0x7fffe4ca3d60, result=0x7fffe4ca3d78) at fcmatch.c:708
#2  0x000000367e017406 in IA__FcFontSort (config=0xcc73e0, p=0xcc73e0, trim=1,
    csp=0x7fffe4ca3d60, result=0x7fffe4ca3d78) at fcmatch.c:836
#3  0x00002aaaab559cf2 in InitFont (fontPtr=0x0, tkwin=0xcc85f0,
    pattern=0xcc73e0) at tkUnixXft.c:168
#4  0x00002aaaab55a146 in TkpGetFontFromAttributes (tkFontPtr=0x0,
    tkwin=0xcc85f0, faPtr=0x7fffe4ca3e20) at tkUnixXft.c:396
#5  0x00002aaaab51d439 in Tk_AllocFontFromObj (interp=0xc400c0,
    tkwin=0xcc85f0, objPtr=0xcc01c0) at tkFont.c:1132
#6  0x00002aaaab565270 in DoObjConfig (interp=0xc400c0,
    recordPtr=<value optimized out>, optionPtr=0xcbfd00, valuePtr=0xcc01c0,
    tkwin=0xcc85f0, savedOptionPtr=0x0) at tkConfig.c:799
#7  0x00002aaaab5656fb in Tk_InitOptions (interp=0xc400c0,
    recordPtr=0xcdc440 "\uffff\205\uffff", optionTable=<value optimized out>,
    tkwin=0xcc85f0) at tkConfig.c:569
#8  0x00002aaaab514a73 in ButtonCreate (clientData=<value optimized out>,
    interp=0xc400c0, objc=4, objv=0x7a32d8, type=1) at tkButton.c:739
#9  0x00002aaaab4f5c7b in Call_Tk (info=<value optimized out>, items=4,
    args=0x7a32d8) at tkGlue.c:2283
#10 0x00002aaaab4f64f9 in XSTkCommand (cv=0x8082d0,
    mwcd=<value optimized out>, proc=0x2aaaab514b60 <Tk_ButtonObjCmd>,
    items=4, args=0x7a32d8) at tkGlue.c:3050
#11 0x00002aaaab4f662f in XStoTclCmdNull (my_perl=0x604010, cv=0x8082d0)
    at tkGlue.c:3064
#12 0x0000003683e90916 in Perl_pp_entersub ()
   from /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#13 0x0000003683e8a1de in Perl_runops_standard ()
   from /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#14 0x0000003683e37e4c in perl_run ()
   from /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#15 0x000000000040179c in main ()
(gdb) p *fnt
Cannot access memory at address 0x2aaaab9e5078
(gdb) l
387         for (i = 0; i < NUM_MATCH_VALUES; i++)
388             value[i] = 0.0;
389
390         i1 = 0;
391         i2 = 0;
392         while (i1 < pat->num && i2 < fnt->num)
393         {
394             FcPatternElt *elt_i1 = &FcPatternElts(pat)[i1];
395             FcPatternElt *elt_i2 = &FcPatternElts(fnt)[i2];
396
(gdb) p pat
$1 = (FcPattern *) 0xcc73e0
(gdb) p *pat
$2 = {num = 22, size = 32, elts_offset = 238864, ref = 1}

Both i1 and i2 are 0.

What version of fontconfig is it?

> What version of fontconfig is it?

Ah, indeed.  This is the current "rawhide", i.e. fontconfig-2.4.1-3.fc6

Created attachment 138589 [details]
results from gdb attached to a process

Attaching gdb to a local process, and with fonts-japanese installed, gives
different trace but again "Cannot access memory at address 0x2aaaab7c85d0"
in FcPatternDestroy() from fcpat.c.  Already freed?

BTW - lines 103 and 104 from tkUnixXft.c in gdb output are actually
behind '#if 0'.

Filed upstream:

  https://bugs.freedesktop.org/show_bug.cgi?id=8665

An update to fontconfig-2.4.2-1.fc7 and tetex-3.0-34.fc7 (the later does
not really change anything and perl-Tk-804.027-10.fc6 remains the same)
did not lick the problem.  I got again:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 46912496218688 (LWP 18967)]
0x0000003664e16c2a in FcCompare (pat=0xcc7900, fnt=0x2aaaab9e6078,
    value=0xcfc4d0, result=0x7fff34b57378) at fcmatch.c:392
392         while (i1 < pat->num && i2 < fnt->num)

with really the same backtrace like in comment #3.  Even that
bad address remains the same:

(gdb) p fnt
$1 = (FcPattern *) 0x2aaaab9e6078
(gdb) p *fnt
Cannot access memory at address 0x2aaaab9e6078

Upstream from comment #7 was marked as a duplicate to a bug
with a status RESOLVED NOTOURBUG even if a fix is supposedly "easy".
Does not look that we see an upstream resolution for a long time.  

Created attachment 144236 [details]
a gdb backtrace from segfault in texdoctk

I reread the original report and there is a difference now.  Then
'texdoctk' was starting and one had to click on "Search" to cause
SIGSEGV.  Now the whole thing just bombs, as described above, when
you simply try to start 'texdoctk' with a display on remote.
OTOH when running with a local display you still have to hit
"Search" and "Quit" to get a bomb like this one.

I found another application using Tcl/Tk which tries to read some
fonts on a startup and right in the middle of that bombs out with
   *** glibc detected *** ical: munmap_chunk():
            invalid pointer: 0x0000000000a0f050 ***   
This happens to be 'ical' patched up and recompiled on rawhide
(source rpm on request).  No idea what else.

Created attachment 146993 [details]
consistent SISEGV in fcpat.c from fontconfig

Ok, so I got ical not to bomb out and that was not a fontconfig problem.

OTOH I am getting a consistent SIGSEGV in fcpat.c from fontconfig-2.4.2-2.fc7
and that one seem to be fontconfig fault.  It is true that FcPatternDestroy
gets a pointer it does not like but it appears that this pointer was
produced earlier with a help of FcConfigSubstitute from fccfg.c.
i.e. by 'fontconfig'.  A number 'nfaces' is set to 26, and those with
numbers from 0 to 14 are valid,  but face 15 causes indigestion.
It does not appear that any of those faces were freed, or otherwise
destroyed, by perl-Tk unless I am missing something.

It indeed appears that I filed that under a wrong component.

The attached gdb trace has some irrelevant lines removed but in
any case this segfault is fully reproducible.

Thanks for the investigation. Will reassign to fontconfig owner...

Well, I guess that one could walk these pointers right after
initialization happened and check if they are valid.  If they indeed
are then either something destroyed some resources in the meantime,
without bothering to record that fact, or something swapped some pointers
and in the moment of SIGSEGV we are looking at something else than
we should.

In a cursory "sanity check" of perl-Tk code I failed to notice anything
of that kind but quite likely this is not so obvious and I as well
could miss the problem.

Or this indeed can be a fontconfig fault; even if some resources
mysteriously vanish when they really should not.

I tried to revisit the issue.  What changed in the meantime is that
while before some action was needed to cause a core dump currently
it is enough to type 'texdoctk'.  If a display is on a remote this
is causing an immediate "Segmentation fault (core dumped)".

Backtrace from a core is practically the same as the one from comment #3
with what looks like a garbage pointer for 'fnt'.

The current version of fontconfig is 2.4.2-2.fc7.

BTW, comments in https://bugs.freedesktop.org/show_bug.cgi?id=8665
suggest indirectly that possibly perlTk is misusing fontconfig API;
although they give not a clue what that possible misuse could be.

While upstream rejected that bug report, as noted in comment #8,
the current rawhide and F7 continue to segfaults.  The trace below
is with fontconfig-2.4.2-3.fc7, tcl-8.4.13-18.fc8 and
perl-Tk-804.027-11.fc7.

Core was generated by `perl /usr/bin/texdoctk'.
Program terminated with signal 11, Segmentation fault.
#0  IA__FcPatternDestroy (p=0x2aaaaf4ef5d0) at fcpat.c:285
285         if (p->ref == FC_REF_CONSTANT)
(gdb) where
#0  IA__FcPatternDestroy (p=0x2aaaaf4ef5d0) at fcpat.c:285
#1  0x00002aaaaefd8b79 in FiniFont (fontPtr=0xce9cf0) at tkUnixXft.c:108
#2  0x00002aaaaef9b49c in Tk_FreeFont (tkfont=0xce9cf0) at tkFont.c:1392
#3  0x00002aaaaefe3c30 in FreeResources (optionPtr=<value optimized out>,
    objPtr=0x0, internalPtr=0xcf90c8 "�\234�", tkwin=0xcdf820)
    at tkConfig.c:1847
#4  0x00002aaaaefe3cca in Tk_FreeConfigOptions (recordPtr=0xcf9000 " |�",
    optionTable=<value optimized out>, tkwin=0xcf7c20) at tkConfig.c:1762
#5  0x00002aaaaef92354 in ButtonEventProc (clientData=0xcf9000,
    eventPtr=<value optimized out>) at tkButton.c:1003
#6  0x00002aaaaef9857d in Tk_HandleEvent (eventPtr=0x7fffeab3eb70)
    at tkEvent.c:1040
#7  0x00002aaaaefdc785 in Tk_DestroyWindow (tkwin=0xcf7c20) at tkWindow.c:1438
#8  0x00002aaaaefdc511 in Tk_DestroyWindow (tkwin=0xca9260) at tkWindow.c:1377
#9  0x00002aaaaefdc511 in Tk_DestroyWindow (tkwin=0xc5eb20) at tkWindow.c:1377
#10 0x00002aaaaef72957 in Check_Eval (interp=<value optimized out>)
    at tkGlue.c:1538
#11 0x00002aaaaef7a4e5 in Tcl_EvalObjEx (interp=0xc40430,
    objPtr=<value optimized out>, flags=<value optimized out>) at tkGlue.c:4368
#12 0x00002aaaaef93525 in ButtonWidgetObjCmd (clientData=0xcc00a0,
    interp=0xc40430, objc=2, objv=0x6e6448) at tkButton.c:890
#13 0x00002aaaaef74b6b in Call_Tk (info=<value optimized out>, items=2,
    args=0x6e6448) at tkGlue.c:2283
#14 0x00002aaaaef67236 in XS_Tk_WidgetMethod (my_perl=0x604010,
    cv=<value optimized out>) at Tk.xs:488
#15 0x0000003593690896 in Perl_pp_entersub ()
   from /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#16 0x000000359368a15e in Perl_runops_standard ()
   from /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#17 0x00000035936375f0 in Perl_call_sv ()
   from /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#18 0x00002aaaae91b2ad in LangCallCallback (sv=0xcb15f0, flags=6)
    at pTkCallback.c:210
#19 0x00002aaaaef7b77d in LangEventCallback (cdata=<value optimized out>,
    interp=0xc40430, event=<value optimized out>, tkwin=<value optimized out>,
    keySym=1) at tkGlue.c:4701
#20 0x00002aaaaef900bf in Tk_BindEvent (bindingTable=<value optimized out>,
---Type <return> to continue, or q <return> to quit---
    eventPtr=0xdadba0, tkwin=0xcb2bf0, numObjects=<value optimized out>,
    objectPtr=<value optimized out>) at tkBind.c:1863
#21 0x00002aaaaef96749 in TkBindEventProc (winPtr=0xcb2bf0, eventPtr=0xdadba0)
    at tkCmds.c:288
#22 0x00002aaaaef98464 in Tk_HandleEvent (eventPtr=0xdadba0) at tkEvent.c:1062
#23 0x00002aaaaef98a2c in WindowEventProc (evPtr=0xdadb90,
    flags=<value optimized out>) at tkEvent.c:1470
#24 0x00002aaaae91c03d in Tcl_ServiceEvent (flags=-3) at ../pTk/tclNotify.c:630
#25 0x00002aaaae91c2be in Tcl_DoOneEvent (flags=-3) at ../pTk/tclNotify.c:871
#26 0x00002aaaaef61673 in XS_Tk_DoOneEvent (my_perl=0x604010,
    cv=<value optimized out>) at Tk.xs:1063
#27 0x0000003593690896 in Perl_pp_entersub ()
   from /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#28 0x000000359368a15e in Perl_runops_standard ()
   from /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#29 0x0000003593637d9c in perl_run ()
   from /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#30 0x00000000004017bc in main ()
(gdb)

Notes from bugzilla at freedesktop.org do not explain me very much.
Anybody with ideas where is really that problem?  gdb only shows
that the whole things trips trying to dereference some pointers,
which look in the same range as other pointers which do not cause
troubles, but which for some reasons are "banned".

Created attachment 158287 [details]
gdb trace from an attempted startup (two breakpoints)

With a display on a remote over a network 'texdoctk' from F7
consistently drops cores.  No need for any actions.  Every attempt
to start simply segfaults in FcFontSort() called by InitFont().

I tried to look with gdb and from what I see InitFont() called at
tkUnixXft.c:168 finds 349 (in my case) fonts and few times runs fine
before things go south. A record from gdb with breakpoints set at
tkFont.c:1055 and tkUnixXft.c:168 is attached.

A content of an emacs buffer of gdb from a run with FC_DEBUG
environment variable set to 3 is also attached.  As you can
see there a fourth attempt to sort is cut rather short.
A string "Font 0 Pattern has" does not show up anymore.
Not that I am much wiser.  Threads clobber each other?

Created attachment 158288 [details]
emacs buffer from gdb with fontconfig debugging info

Created attachment 274181 [details]
texdoctk from tetex-3.0-44.3.fc8 trace segfaulting on a local display

The situation only got worse with F8.  I asked somebody with
an i386 installation of F8 to type 'texdoctk' and it immediately
segfaulted on a __local__ display.  It does that on every try.

A new bug 375131, where xfs is killed, could be related.

See also comments #2 and #3 in bug 416861(that one for F8).

perl-Tk-804.028-1.fc8 has been pushed to the Fedora 8 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 perl-Tk'

perl-Tk-804.028-1.fc7 has been pushed to the Fedora 7 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 perl-Tk'

After an update to perl-Tk-804.028-1 this works for me; both with
a local display and on a remote.  Thanks!

perl-Tk-804.028-1.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.

perl-Tk-804.028-1.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.