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
