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

[Charles Lee]

OK. Thanks Phil.

On 03/14/2012 09:00 PM, Phil Race wrote:
> 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?
>>>>
>>>
>>
>>
>


-- 
Yours Charles