[OpenJDK 2D-Dev] JVM Crash: printing character \u0DDD in Swing app

[Igor Nekrestyanov]

Hi Patrick,

thank you for tracking down this problem.

>> to simplify testcase please do the following:
>>  1) render to the offscreen bufferedimage, so no swing will be involved
>>     
>
> Like this? (in a loop)
> BufferedImage bimg = gconf.createCompatibleImage(100, 100);
> Graphics g = bimg.getGraphics();
> g.setFont(font);
> g.drawString(Character.toString('\u0DDD'), 0, 0);
> g.dispose();
>   
yes, this is fine (or you can use new BufferedImage() - saves few lines 
of code :) ).
Please:
 
1) make sure that font size and other attributes are reasonable.
    By default you might be rendering fonts of size 1 and then lots of 
shortcuts will be taken in the font library code
     (it does not have sense to be too smart if everything is inside 1 
pixel)

2) It is better to use not getAllFonts(). Use Font.createFont() on 
particular font file.
    For this test you will need to collect list of .ttf/.ttc/.pfa/.pfb 
files from your system and
    use them as input. This will make sure we know exact font file and 
we can look into the font.

    I.e. the test gets filename as parameter, tries to render this glyph 
and exits.
    And you can run it on each file from the list using simple shell 
script that also prints filename to be tested.

    The true goal of this exercise is to spot font file which causes 
crash and identify the way how we use it.
    Swing is touching several fonts including logical fonts and this 
adds some noise. That's why i asked to take Swing out of equation.

 From your other mails it seems you can reproduce crash on particular 
font file but with openjdk only.
This is actually very good start. It can be either problem in the shared 
code or bugs in both rasterizers (freetype and t2k).
Obviously shared code seems to be more probable :) E.g. this can be 
memory smash and in case of Sun's Java we are lucky
and corruption does not affect important memory areas.

Can you send me font file causing problem and your test, so i can try 
this myself?
You may also try to update your Swing test and set component font to one 
you found explicitly - will it still crash with Sun's JDK?

-igor
>   
>>  2) iterate through list of font files, we need to find which font exactly
>> causes the problem
>>     
>
> Ok, but will need to run from a shell script that iterates over the
> font list, as the crash is a hard crash (and on a quick test, caused
> by the very first font returned by getAllFonts() :)).
>
> Let me know if the above is a good way to code that, haven't worked
> with those APIs in awhile.
>
> Thanks
> Patrick
>