Fontconfig - Nov 2005 - Xft2 on topic? If so, what could cause XftDrawDepth hangs on a multiprocessor machine?

Around 12 o''clock on Apr 1, Stefaan A Eeckels wrote:

| Attached to process 6139 with 3 LWPs
| t@1 (l@1) stopped in _poll at 0xff29dbb4
| 0xff29dbb4: _poll+0x0004:       ta      %icc,%g0 + 8
| (dbx) where
| current thread: t@1
| =>[1] _poll
| [2] _select
| [3] _ti_select
| [4] _XWaitForReadable
| [5] _XRead
| [6] _XReply
| [7] XGetGeometry
| [8] XftDrawDepth
| [9] XftGlyphFontSpecCore
| [10] XftDrawGlyphFontSpec
| [11] nsFontMetricsXft::DrawString

Any chance you could use xscope, xmon or some other protocol tracing tool 
to see whether the request and reply are actually exchanged here?

There were bugs in the locking code inside the Xrender library; if you 
have an older version of that, that might be causing trouble.  You should 
be able to check this by disabling use of the Render extension from Xft 
by setting an X resource before starting Mozilla:

$ xrdb -merge << EOF
Xft.render: false
EOF

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url :
http://lists.freedesktop.org/archives/fontconfig/attachments/20050401/7bba03e4/attachment.pgp

Hi all,

Is it appropriate to ask a question concerning libXft2 here?
I looked at the mailing lists on freedesktop.org and couldn''t
find anything suitable. 

On my dual-processor Sun Firefox hangs in the XftDrawDepth
routine, as shown in the simplified dbx output below:

| Attached to process 6139 with 3 LWPs
| t@1 (l@1) stopped in _poll at 0xff29dbb4
| 0xff29dbb4: _poll+0x0004:       ta      %icc,%g0 + 8
| (dbx) where
| current thread: t@1
| =>[1] _poll
| [2] _select
| [3] _ti_select
| [4] _XWaitForReadable
| [5] _XRead
| [6] _XReply
| [7] XGetGeometry
| [8] XftDrawDepth
| [9] XftGlyphFontSpecCore
| [10] XftDrawGlyphFontSpec
| [11] nsFontMetricsXft::DrawString

It happens frequently when firefox is not bound to a CPU,
and occasionally when bound, indicating a threading issue
of sorts. Other GTK2 programs on my machine do not exhibit
this behaviour. 

Anybody seen this before? 

Thanks!

-- 
Stefaan
-- 
As complexity rises, precise statements lose meaning,
and meaningful statements lose precision. -- Lotfi Zadeh