RFR(XS) 8191852: Null pointer dereference in ciKlass::get_Klass of ciKlass.hpp:58

Vladimir Kozlov vladimir.kozlov at oracle.com
Thu Dec 14 00:20:05 UTC 2017


On 12/13/17 3:09 PM, dean.long at oracle.com wrote:
> On 12/13/17 1:08 PM, Vladimir Kozlov wrote:
> 
>> On 12/13/17 12:45 PM, dean.long at oracle.com wrote:
>>> https://bugs.openjdk.java.net/browse/JDK-8191852
>>> http://cr.openjdk.java.net/~dlong/8191852/webrev/
>>>
>>> Our static analysis tool was complaining about a possible null 
>>> pointer dereference in ciKlass::get_Klass(), because of this code:
>>>
>>> 237.      _holder = CURRENT_ENV->get_instance_klass(fd->field_holder());
>>> [...]
>>> 240.      Klass* k = _holder->get_Klass();
>>>
>>> so I added NULL checks in get_instance_klass and a few other similar 
>>> functions.
>>
>> No, you don't ;)
> 
> Yes, you're right.  Sorry about that :-)
> 
>> You replaced NULL checks which return NULL with asserts. It is not the 
>> same. Are you sure that in all those cases we will not get NULL?
> 
> It didn't show up in my testing.  But what I could try is to remove the 
> asserts and rerun the static analysis.  Then get_instance_klass() would be:
> 
>    ciInstanceKlass* get_instance_klass(Klass* o) {
>      return get_metadata(o)->as_instance_klass();
>    }
> 
> In the first example above, static analysis would need to verify that 
> fd->field_holder() can never return NULL.  If that sounds reasonable, 
> I'll rerun the static analysis.

Yes, it is reasonable.

Thanks,
Vladimir

> 
> dl
> 
>>
>> Thanks,
>> Vladimir
>>
>>>
>>> dl
> 


More information about the hotspot-compiler-dev mailing list