[OpenJDK 2D-Dev] Segment fault when loading sun.font.StrikeCache at first

Phil Race philip.race at oracle.com
Wed Mar 14 13:00:19 UTC 2012


On 3/13/12 10:13 PM, Charles Lee wrote:
> Hi Phil,
>
> I guess it is
>
> "sun.font.StrikeCache.getStrikeRef(null);"
>
> "getStrikeRef" is a public api from a public class in a not so public 
> package.:-)

No, its not a public API. Its internal and private to the JDK.
Any app calling it directly gets what it deserves.
>
> Here is the story:
> The problem is emitted from one of our VM classloading robust test 
> case. The patch is trivial, but since it will cause VM crash, I am 
> trying to give it a shot.

No, its completely unnecessary, There's probably a gazillion places that
code expects to be called in a certain order.

Bottom line: the test case isn't valid, and so/nor is the patch so its 
rejected.

-phil.

>
>
> On 03/14/2012 01:40 AM, Phil Race wrote:
>> Do you have a public API level program that exhibits this ?
>>
>> I don't consider the internal test you provide as a valid execution path
>> that needs this attention.
>>
>> -phil.
>>
>> On 3/13/12 12:16 AM, Charles Lee wrote:
>>> Hi guys,
>>>
>>> I have create a sunbug @ 
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7153293
>>>
>>> It is mainly about:
>>> When loading sun.font.StrikeCache before sun.font.SunFontManager (or 
>>> something else), there will be an UnsatisfiedLinkError thrown. The 
>>> reason is there is a native call in its static initialize block, but 
>>> the native library is not loaded in yet.
>>> The problem will do harm, if user load SunFontManager after failing 
>>> on loading StrkeCache. You will see a VM crash occurred.
>>> The problem will do more harm, because user can never load 
>>> StrikeCache, SunLayoutEngine successfully.
>>>
>>> The patch is @ http://cr.openjdk.java.net/~littlee/7153293/webre.00/ 
>>> <http://cr.openjdk.java.net/%7Elittlee/7153293/webre.00/>
>>> It is straightforward. Just loading the native library at the 
>>> beginning of static initializer of StrikeCache.
>>>
>>> Would anyone help to review this?
>>>
>>
>
>




More information about the 2d-dev mailing list