RFR(S) 8235220: ClhsdbScanOops.java fails with sun.jvm.hotspot.types.WrongTypeException

[Alex Menkov]

Looks good.

--alex

On 04/13/2020 11:45, Chris Plummer wrote:
> Ping! Can I get one more review please.
> 
> thanks,
> 
> Chris
> 
> On 4/9/20 10:21 PM, Ioi Lam wrote:
>> Hi Chris,
>>
>> Thanks for fixing this. It looks good to me.
>>
>> - Ioi
>>
>> On 4/9/20 9:44 PM, Chris Plummer wrote:
>>> Hello,
>>>
>>> Please review the following:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8235220
>>> http://cr.openjdk.java.net/~cjplummer/8235220/webrev.00
>>>
>>> First off, thanks to Ioi for tracking this one down and proposing the 
>>> fix.
>>>
>>> The test is executing the clhsdb "scanoops" command, which scans the 
>>> specified heap address range looking for objects of the specified 
>>> type (or all objects if no type is specified). The test determines 
>>> the address range by first using clhsdb "universe" to get the start 
>>> and end of the eden space. scanoops then iterates over this entire 
>>> range, calling RobustOopDeterminator.oopLooksValid() on each oop as 
>>> it iterates over the range. The problem is eventually you'll end up 
>>> past the initialized part of the heap. That causes 
>>> VirtualBaseConstructor.findDynamicTypeForAddress() to return null, 
>>> resulting in throwing a WrongTypeException. 
>>> RobustOopDeterminator.oopLooksValid() should catch this exception and 
>>> return false when it happens.
>>>
>>> The CR mentions a few different failure modes. This only fixes the 
>>> WrongTypeException failure. The NullPointerException is only on OSX 
>>> and I believe is the same as JDK-8241158 [1], which happens when 
>>> dumping the heap, so it seems probable that it is also turning up 
>>> when scanning part of the heap. I think this bug was preventing us 
>>> from ever seeing the WrongTypeException on OSX. Then there also 
>>> JDK-8230731 [2] on Windows, which seems to prevent ever seeing the 
>>> WrongTypeException on Windows.
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8241158
>>> [2] https://bugs.openjdk.java.net/browse/JDK-8230731
>>>
>>> thanks,
>>>
>>> Chris
>>
>