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

[Staffan Larsen]

> On 4 mar 2015, at 12:29, Kevin Walls <kevin.walls at oracle.com> wrote:
> 
> 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;

Should duplicateDefCount really be static?

For the use of duplicateDefCount on line 477 (readVMStructs()) I do not see where it is increased inside the loop? Can you clarify?

/Staffan

> 
> 
> 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
>> 
>