RFR: 8073688: Infinite loop reading types during jmap attach.

[Kevin Walls]

Hi,

Yes that's true - the original problem is in 7u.  We'll have it around 
for a while yet so I would like to get this change there to protect us.

While we can't reproduce the same thing on 9 today, there's still a 
while loop that will never terminate if we read a zero for the stride 
size, for example.  I think it's worth protecting ourselves from that 
kind of problem.

Thanks
Kevin

On 03/03/2015 13:51, Mikael Gerdin wrote:
> Kevin,
>
> On 2015-03-03 14:15, Kevin Walls wrote:
>> Hi,
>>
>> This is a review request for a way to make the SA tools protect
>> themselves from infinite loops during initialisation.
>>
>> Attaching jmap (for example) to a JVM can fail, infinitely writing an
>> error - and filling a disk if being logged to a file.  This reproduces
>> on a Solaris package based install, but not with other distribution
>> bundles.  In those packages, there's a link JDK/jre/lib/sparc/libjvm ->
>> client/libjvm.so.  If a server/libjvm.so is loaded and running, we see
>> libverify.so pull in client/libjvm.so, as it finds the symlink in its
>> $ORIGIN, in preference to finding the already loaded libjvm.so.
>
> There is only server/libjvm.so on Solaris since JDK 8, so I assume 
> that this RFR is for JDK 7u only. The late stage of the JDK 7u updates 
> project should perhaps be considered when looking at this change.
>
> /Mikael
>
>>
>> Symbol lookup in the SA is fooled by having multiple libjvm.so loaded.
>> There are various things wrong with that.  Protection against zero
>> strides through the type arrays and a maximum count for duplicated types
>> will protect us from a few possible problems.
>>
>> I'll also work a bug for the "install" repo where we create that
>> symlink, but the tools need to protect themselves from this kind of
>> problem.
>>
>> Testing was manual.
>>
>> bug
>> https://bugs.openjdk.java.net/browse/JDK-8073688
>>
>> webrev
>> http://cr.openjdk.java.net/~kevinw/8073688/webrev.00/
>>
>> Thanks
>> Kevin