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
