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

[Kevin Walls]

Thanks Dmitry -

I will explain the counter's presence where we introduce it:

   // Counter to ensure read loops terminate:
   private static final int MAX_DUPLICATE_DEFINITIONS = 100;
   private static int duplicateDefCount = 0;


Thanks
Kevin


On 03/03/2015 20:10, Dmitry Samersoff wrote:
> Kevin,
>
> The fix looks good for me, but please add a comment explaining the
> problem we are solving here.
>
> -Dmitry
>
> On 2015-03-03 16: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.
>>
>> 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
>