> On 4 mar 2015, at 12:29, Kevin Walls <kevin.wa...@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 >> >
