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

[Mikael Gerdin]

On 2015-03-03 14:57, Kevin Walls wrote:
>
> 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.

That's probably a good idea to fix then.

I'll leave the rest for people who are qualified to review the code :)

/Mikael

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