Bug 210718 - perl-Tk - SIGSEGV on exit from texdoctk
perl-Tk - SIGSEGV on exit from texdoctk
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: fontconfig (Show other bugs)
8
All Linux
medium Severity medium
: ---
: ---
Assigned To: Behdad Esfahbod
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-13 17:03 EDT by Michal Jaegermann
Modified: 2008-01-06 20:29 EST (History)
3 users (show)

See Also:
Fixed In Version: 804.028-1.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-06 20:29:19 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
tail of 'strace' output (54.81 KB, text/plain)
2006-10-13 17:03 EDT, Michal Jaegermann
no flags Details
results from gdb attached to a process (4.38 KB, text/plain)
2006-10-16 12:54 EDT, Michal Jaegermann
no flags Details
a gdb backtrace from segfault in texdoctk (3.87 KB, text/plain)
2006-12-21 19:43 EST, Michal Jaegermann
no flags Details
consistent SISEGV in fcpat.c from fontconfig (5.78 KB, application/octet-stream)
2007-01-30 20:40 EST, Michal Jaegermann
no flags Details
gdb trace from an attempted startup (two breakpoints) (1.26 KB, text/plain)
2007-06-30 03:32 EDT, Michal Jaegermann
no flags Details
emacs buffer from gdb with fontconfig debugging info (4.08 MB, text/plain)
2007-06-30 03:35 EDT, Michal Jaegermann
no flags Details
texdoctk from tetex-3.0-44.3.fc8 trace segfaulting on a local display (280.97 KB, text/plain)
2007-11-30 14:09 EST, Michal Jaegermann
no flags Details

  None (edit)
Description Michal Jaegermann 2006-10-13 17:03:29 EDT
Description of problem:

With perl-Tk installed start 'texdoctk', click on "Search", type
something to find there (say, "setspace"), select "Cancel" in
"Search results" window and "Quit".  This terminates with
"Segmentation fault" message.  Last part of 'strace' output is
attached.  One can notice there repeating:

ioctl(6, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffbfe58730) = -1 ENOTTY
(Inappropriate ioctl for device)

although I do not know if this is a problem. 'texdoctk' is a part
of tetex-3.0-32.fc6 package.

If you will skip search but pick up some docs using other buttons
then, after these docs were viewed or not, texdoctk exits cleanly.

It is possible that 'texdoctk' has problems but it does not seem
to be that way after a quick peek at this code.  Also the same version
of 'texdoctk', i.e. "texdoctk v.0.6.0 (Nov 5, 2004)" is used with
tetex-3.0-29.fc5 and on FC5 installation, also x86_64, there are
no segfaults or other surprises I can find.

As an additional data point - when I tried to start 'texdoctk'
on a remote display over ssh (that connection allows that and other
programs are starting just fine) this ended up with 
"Segmentation fault (core dumped)".  I have limit set to allow cores
on a test installation.  Once again - there are no such problems with FC5.

Here is a backtrace from this core:

Core was generated by `perl /usr/bin/texdoctk'.
Program terminated with signal 11, Segmentation fault.
#0  0x000000367e016aaa in FcFontSetSortDestroy ()
   from /usr/lib64/libfontconfig.so.1
(gdb) bt
#0  0x000000367e016aaa in FcFontSetSortDestroy ()
   from /usr/lib64/libfontconfig.so.1
#1  0x000000367e016ef4 in FcFontSetSort () from /usr/lib64/libfontconfig.so.1
#2  0x000000367e017406 in FcFontSort () from /usr/lib64/libfontconfig.so.1
#3  0x00002aaaab559cf2 in TkpDeleteFont ()
   from /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/auto/Tk/Tk.so
#4  0x00002aaaab55a146 in TkpGetFontFromAttributes ()
   from /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/auto/Tk/Tk.so
#5  0x00002aaaab51d439 in Tk_AllocFontFromObj ()
   from /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/auto/Tk/Tk.so
#6  0x00002aaaab565270 in Tk_RestoreSavedOptions ()
   from /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/auto/Tk/Tk.so
#7  0x00002aaaab5656fb in Tk_InitOptions ()
   from /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/auto/Tk/Tk.so
#8  0x00002aaaab514a73 in TkButtonWorldChanged ()
   from /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/auto/Tk/Tk.so
#9  0x00002aaaab4f5c7b in Call_Tk ()
   from /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/auto/Tk/Tk.so
#10 0x00002aaaab4f64f9 in XSTkCommand ()
   from /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/auto/Tk/Tk.so
#11 0x00002aaaab4f662f in XSTkCommand ()
   from /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/auto/Tk/Tk.so
#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 ()

and a tail from strace:
....
--- SIGCHLD (Child exited) @ 0 (0) ---
lseek(6, 186, SEEK_SET)                 = -1 ESPIPE (Illegal seek)
close(6)                                = 0
rt_sigaction(SIGHUP, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGINT, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN}, {SIG_DFL}, 8) = 0
wait4(3060, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 3060
rt_sigaction(SIGHUP, {SIG_DFL}, NULL, 8) = 0
rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL}, NULL, 8) = 0
munmap(0x2aaaab9e5000, 8264)            = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV (core dumped) +++


I do not know if the problem is really limited to x86_64 (and
it is possible that the problem is really more fundamental).

Version-Release number of selected component (if applicable):
perl-Tk-804.027-10.fc6

How reproducible:
always in circumstances like described
Comment 1 Michal Jaegermann 2006-10-13 17:03:29 EDT
Created attachment 138462 [details]
tail of 'strace' output
Comment 2 Michal Jaegermann 2006-10-15 14:37:52 EDT
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?
Comment 3 Michal Jaegermann 2006-10-15 15:16:13 EDT
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.
Comment 4 Behdad Esfahbod 2006-10-16 11:22:02 EDT
What version of fontconfig is it?
Comment 5 Michal Jaegermann 2006-10-16 11:54:42 EDT
> What version of fontconfig is it?

Ah, indeed.  This is the current "rawhide", i.e. fontconfig-2.4.1-3.fc6
Comment 6 Michal Jaegermann 2006-10-16 12:54:20 EDT
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'.
Comment 7 Behdad Esfahbod 2006-10-16 14:11:47 EDT
Filed upstream:

  https://bugs.freedesktop.org/show_bug.cgi?id=8665
Comment 8 Michal Jaegermann 2006-12-21 19:15:24 EST
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.  
Comment 9 Michal Jaegermann 2006-12-21 19:43:39 EST
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.
Comment 10 Michal Jaegermann 2006-12-21 20:02:59 EST
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.
Comment 11 Michal Jaegermann 2007-01-30 20:40:54 EST
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.
Comment 12 Andreas Bierfert 2007-01-31 03:02:35 EST
Thanks for the investigation. Will reassign to fontconfig owner...
Comment 13 Michal Jaegermann 2007-01-31 14:14:15 EST
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.
Comment 14 Michal Jaegermann 2007-04-04 21:01:51 EDT
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.
Comment 15 Michal Jaegermann 2007-04-04 21:07:53 EDT
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.
Comment 16 Michal Jaegermann 2007-06-02 16:38:46 EDT
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".
Comment 17 Michal Jaegermann 2007-06-30 03:32:29 EDT
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?
Comment 18 Michal Jaegermann 2007-06-30 03:35:18 EDT
Created attachment 158288 [details]
emacs buffer from gdb with fontconfig debugging info
Comment 19 Michal Jaegermann 2007-11-30 14:09:36 EST
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.
Comment 20 Michal Jaegermann 2007-12-30 13:24:15 EST
See also comments #2 and #3 in bug 416861(that one for F8).
Comment 21 Fedora Update System 2008-01-02 20:34:53 EST
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'
Comment 22 Fedora Update System 2008-01-02 20:35:54 EST
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'
Comment 23 Michal Jaegermann 2008-01-03 17:43:47 EST
After an update to perl-Tk-804.028-1 this works for me; both with
a local display and on a remote.  Thanks!
Comment 24 Fedora Update System 2008-01-06 20:17:56 EST
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.
Comment 25 Fedora Update System 2008-01-06 20:29:14 EST
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.

Note You need to log in before you can comment on or make changes to this bug.