After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 318863 - browser | clicking Hebrew Links leads to assersion
browser | clicking Hebrew Links leads to assersion
Status: RESOLVED DUPLICATE of bug 314239
Product: pango
Classification: Platform
Component: general
1.10.x
Other All
: High critical
: ---
Assigned To: pango-maint
pango-maint
Depends on:
Blocks:
 
 
Reported: 2005-10-14 12:30 UTC by Shai
Modified: 2006-02-21 11:38 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12



Description Shai 2005-10-14 12:30:08 UTC
Steps to reproduce:
1. open firefox
2. goto www.ynet.co.il click on one of the links in hebrew
3. the window is acting wierd, close and refresh a few times then the headers of
all the windows in the gnome disapears
the x log shows this 

Window manager warning: Log level 6: file hebrew-fc.c: line
314(hebrew_engine_shape): assertion failed: (face)





Stack trace:
i'm not sure which proccess crashes... i'd add a trace if i'll get any pointers 

Other information:
Comment 1 Shai 2005-10-14 12:32:01 UTC
easy to reproduce via any browser (gleon etc')
note: i'm using gentoo
Comment 2 Christian Persch 2005-10-14 13:31:57 UTC
I can confirm that this page makes epiphany extremely slow (well, or maybe it's
going to hang forever, didn't take enough time to find out). It's using 100% CPU
and when I interrupt it and it happens to be in pango, it is this (or below this):

  • #0 pango_glyph_string_extents_range
    at glyphstring.c line 226
  • #1 pango_glyph_string_extents
    at glyphstring.c line 255
  • #2 pango_layout_run_get_extents
    at pango-layout.c line 3863
  • #3 pango_layout_line_get_extents
    at pango-layout.c line 3962
  • #4 NSGetModule
    from /usr/lib/mozilla-firefox/components/libgfx_gtk.so
  • #5 NSGetModule
    from /usr/lib/mozilla-firefox/components/libgfx_gtk.so
  • #6 NSGetModule
    from /usr/lib/mozilla-firefox/components/libgklayout.so
  • #7 NSGetModule
    from /usr/lib/mozilla-firefox/components/libgklayout.so

However it's far from clear that this is a pango problem and more likely a
firefox problem. In firefox trunk it doesn't hang but is still extremely slow,
proabably due to the ridiculously heavy flash usage on that page.

Suggesing NOTGNOME.
Comment 3 Shai 2005-10-14 19:08:30 UTC
i've reproduced it using epiphany as well (again the same behavior) i believe
it's the window manager that is crashing (it worked fine till the last update
i've had last night to the gnome... )
if i knew which proccess is the window manager i could produce a trace (p.s the
firefox or any other broswer doesn't crash, only the window manager )
Comment 4 Shai 2005-10-20 15:41:38 UTC
i've found why it crashed the metacity.
i've copied into /usr/share/fonts/TTF the fonts i've been using in windows
these files were masked with no read permission to regular users.
in the perviouse versions of pango or metacity that wasn't a problem (it was
handles correctly - it just didn't use them)
with the current gnome/pango/metacity the metacity crashes
i guess it's not critical but it is a regression from previous versions. 
Comment 5 Behdad Esfahbod 2005-10-20 15:43:48 UTC
Quite possible that it's a Cairo bug.
Comment 6 Owen Taylor 2005-11-14 06:20:02 UTC
Crashes for me with Epiphany inside Pango - the backtrace looks screwed 
up so some valgrind action would be useful. I'd tend to blame the Hebrew
shaper rather than Cairo ... A cairo bug would be unlikely to show up 
just on this one page.
Comment 7 Owen Taylor 2005-11-17 04:39:46 UTC
I actually hit this (or something like this) myself with an incoming mail
in evo. It turned out to be a combination of:

 - Decreased robustness against missing fonts (sort of bug 314239)
   Pango was never good, but it seems to be considerably worse these
   days.

 - fontconfig problems. It never seems to correct out of date information 
   in ~/.fonts.cache-2.

   rm ~/.fonts.cache-2 was how I "fixed" the problem for myself - it
   was pointing to a font that I moved to a different place months
   ago.
Comment 8 Behdad Esfahbod 2005-11-17 04:46:22 UTC
~/.fonts.cache-2 stuff is really new and experimental.  Getting better everyday.
Comment 9 Behdad Esfahbod 2006-02-21 11:38:08 UTC

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