Closed Bug 192397 Opened 22 years ago Closed 19 years ago

Font sizes over 300pt crash mozilla built with xft and gtk2

Categories

(Core Graveyard :: GFX: Gtk, defect)

Product:
Core Graveyard
Component:
GFX: Gtk
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: hile, Assigned: blizzard)

References

Details

(Keywords: crash, relnote)

Attachments

(2 files, 1 obsolete file)

stacktrace
9.99 KB, text/plain
Details
Testcase
120 bytes, text/html
Details 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030130
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030130

Trying to use too big font sizes crashes mozilla instantly, if it's compiled
with XFT2 and gtk2 support. 

I don't know if this is XFT2 or mozilla bug, none of my gnome 2.2. apps allow me
to set that big font, except gimp 1.3, which might do something different.

Anyway, this was an issue with 1.0.x as well, maybe the fix didn't make it to
gtk2 version?

Reproducible: Always

Steps to Reproduce:
1. Go to page http://hile.dyndns.org/crashme.html
2. Either you get instant crash or this bug is not reproducable



Expected Results:  

Well, not crashed ;)

I'm using debian's latest build of mozilla-snapshot. Could not find any xft2 
enabled other builds, so I'm not 100% sure this is not debian bug.
Ah, bug 150339 seems to have come back from its grave ! We'll limit the max
font-size to twice the display-size, but that may not be enough for gtk2.
This test works just fine on my Red Hat rawhide system.
Attached file stacktrace (obsolete) — 
stacktrace from CVS XFT/gtk2 build rendering testcase with 800pt instead of
400pt.	the 400pt testcase did not crash.  800pt worked ok in gtk1 build.
marking NEW
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash
Relevant Debian build options for this version were:
       --with-default-mozilla-five-home=/usr/lib/mozilla$(TAG) \
       --disable-debug \
       --disable-tests \
       --disable-short-wchar \
       --enable-xprint \
       --enable-optimize="-pipe -w $(OPTFLAGS)" \
       --enable-strip-libs \
       --enable-crypto \
       --enable-mathml \
       --enable-oji \
       --enable-extensions=all \
       --with-system-zlib \
       --enable-default-toolkit=gtk2 \
       --enable-ldap \
       --enable-xft 

Maybe this helps debugging it. And yes, this bug is not in gtk1 version which is
 available as nightly build, but that version isn't compiled --enable-xft at all
so it's quite different anyway.

I'll build an CVS version with above flags and see what happens on debian with
that. 
Can you get a stack trace with --sync?

Are you using this against an X server without RENDER support, by any chance?
Well, running mozilla --sync gives only this:
The program '<unknown>' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadLength (poly request too large or internal Xlib length erro'.
  (Details: serial 4217 error_code 16 request_code 155 minor_code 20)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

And yes, of course I have RENDER ...  but in addition, this particular machine
has experimental DRI support as well, forgot this totally. I'll try with
something else and see if I still have problems.

No, experimental DRI drivers didn't make any difference.
> Can you get a stack trace with --sync?

attachment 113931 [details] is with --sync

> Are you using this against an X server without RENDER support

running Red Hat 8.0 XFree86 4.2.0-72.
And if you use GDK_USE_XFT=0?
With GDK_USE_XFT=0 no crash, the font is just rendered too small: see screenshot, 
http://hile.dyndns.org/mozilla-noxft-400pt.png. I know we limit the size, but 
this small?!? 

With a build using xft and gtk1 font size is ok and it doesn't crash. 

BTW, I think we are using xft2 for gtk2 builds, and xft1 for gtk1 builds? Could 
this make the difference?
Uhh.  That's really strange.
This seems to be a bug in my X-server after all, or a combination of fontconfig
2.x and my X-server. The server's configuration is available, if interested, from 
http://hile.dyndns.org/configs/omnibook500/etc/X11/XF86Config-4

On another machine, with same software versions but different X-server, the page
is shown but completely incorrectly, see screenshot in 
http://hile.dyndns.org/screenshots/mozilla-badrender.png

The letters are cut to about 25% percent from left, could this be a buffer size
problem?
There might be a clip region involved in that cut off text - hard to say.
I got the cut-off text at 400pt and a crash (attachment 113931 [details]) at 800pt.
Blocks: 198231
Attached file stacktrace — 
I tried this again with current CVS and got a completely different stack.  But
I was almost certain I had done --sync for the first one.  Oh well.

this one makes more sense
Attachment #113931 - Attachment is obsolete: true
No longer blocks: 198231
*** Bug 198231 has been marked as a duplicate of this bug. ***
It's not a duplicate of bug 150339.  Bug 150339 is a problem with the
Type 1 backend used in XFree86 4.2 and earlier, and crashes the X server
(or the font server if you happen to be running one).  

This one causes a protocol-level error, and looks like it might be related
to Xft. It's clearly the same as Bug 198231.

I'd really like to see this bug clarified before you decide to work
around it by limiting the size of fonts.

It might actually be a bug in nsImageGTK.  It's possible that nsImageGTK
is doing overly large GetImage requests, and hence gets BadLength errors.

With XFree86, GetImage should be able to handle up to 4 MB of data in one,
go so that surprises me a bit.  Still, if that's the case the solution would
be to have nsImageGTK split the request into smaller tiles.

That would also be good for interactivity, as the X server treats requests
atomically.

*** Bug 213966 has been marked as a duplicate of this bug. ***
*** Bug 220318 has been marked as a duplicate of this bug. ***
adding Keith to cc to see if he can offer an insight.
I didn't account for such large glyphs in the Render extension design; the 'O'
is over 4MB and doesn't fit in the largest available X request.  We can fix this
in several possible places:

 1)  Render.  Add requests to build glyphs incrementally.  Should probably do this.
 2)  Xft.  Check font/glyph size and fall back to client-side rendering when
they're too large.
 3)  Mozilla.  Check pixel size and set XFT_RENDER to FC_FALSE for really large
fonts.
 4)  fonts.conf.  Same as mozilla, except no recompile is needed and it will fix
all apps.

Here's a sample fix you can stick in /etc/fonts/fonts.conf to test; Mozilla can
perform this test in code instead of needing to edit the configuration.

<match target="font">
        <test name="pixelsize" compare="more">
                <int>200</int>
        </test>
        <edit name="render">
                <bool>false</bool>
        </edit>
</match>

There should already be a define for this to save us from the deadly X font server:

http://lxr.mozilla.org/seamonkey/search?string=FONT_MAX_FONT_SCALE

do we need a hard coded number to avoid this?
You can guess the maximum pixel size supported by Render from the maximum
request size; it can't be perfect because glyphs may be really wide, while the
pixel size relates only to height, plus 'pixel size' may not relate to actual
glyph size in any meaningful way.  Adding generous padding to the estimates for
the area of the glyph will probably do just fine:

      max_pixels = max_request - 50
      max_height = sqrt (max_pixels / 3)

this assumes that fonts are no more than three times as wide as the height of
the font; you may want to be even more conservative.

*** Bug 224181 has been marked as a duplicate of this bug. ***
Keith, would you add that config option to a fontconfig release later? It seems
better that way because it works for all apps. Nonetheless, Mozilla can be
defensive.
I'll add a fix to Xft so that other applications won't hit this problem.  I
think it'll be equivalent to the fix in Mozilla, so there's no reason to remove
that.  It will, however, be more accurate in using actual font metrics rather
than just guessing based on the pixel height.
*** Bug 225763 has been marked as a duplicate of this bug. ***
*** Bug 228483 has been marked as a duplicate of this bug. ***
Has this one been fixed?
*** Bug 210991 has been marked as a duplicate of this bug. ***
*** Bug 212888 has been marked as a duplicate of this bug. ***
Still crashes with :
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040406 Firefox/0.8.0+
See comment #25. If it's not added to fontconfig, yet, we have to add it to the
release note.
Keywords: relnote
The bug fix goes in Xft.  I thought I'd applied this months ago, but can't find
any trace of it in current Xft sources...
WFM with a self-made trunk build from yesterday and the following build options:

--enable-calendar
--disable-freetype2
--enable-xft
--enable-crypto
--enable-extensions=wallet,irc,help,inspector,typeaheadfind,xml-rpc,xmlextras,venkman,p3p,cookie,content-packs
--enable-svg
--enable-svg-renderer-libart
--disable-installer
--enable-default-toolkit=gtk2

Was this fixed somehow? Can anyone still reproduce this crasher?
*** Bug 241083 has been marked as a duplicate of this bug. ***
this worksforme with xft/trunk.  I increased the font size up to 1600pt with no
crash.  Any increase beyond that was ignored (font size stayed at ~1600pt).
Someone *please* review this patch and apply it if it's good enough. There is at
least one website which makes Mozilla/Firefox crash due to this bug:
http://home.mn.rr.com/aikousha/
Yes it abuses the BIG tag but Mozilla should not crash.
*** Bug 260159 has been marked as a duplicate of this bug. ***
*** Bug 268052 has been marked as a duplicate of this bug. ***
Attached file Testcase — 

    
    

    
  
Fixed when tested on Firefox 1.5 RC1 Linux (build from the Mozilla site).
URL: http://hile.dyndns.org/crashme.html
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED

    
  
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

    
  
Sorry for the bugspam, marking WFM as this is the correct resolution as no fix was identified for the problem.
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → WORKSFORME

    
    

    
  
*** Bug 317200 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: