Details
-
Bug
-
Resolution: Fixed
-
P4
-
8
-
b04
Description
This is similar to the issue fixed (and hopefully backported to 8) with JDK-8194246. That one fixed the "methods" array that is declared as "short[]", handles "u2" elements, but mistakenly accessed as "short", not "ushort".
There is a similar trouble with "cprefs" array, that is declared as "short[]", handles "u2" elements, and yet again accessed as "short". Note thatJDK-8140685 rewired this to short T_LONG/T_INT as the Symbol* address.
This means we have a problem in 8u, but not anywhere else.
This is fairly easy to reproduce on the test case fromJDK-8194246, if we simulate redefinition by doing this:
// The method can be NULL if the requested class version is gone
- Symbol* sym = (method != NULL) ? method->name() : holder->constants()->symbol_at(cpref);
+ Symbol* sym = holder->constants()->symbol_at(cpref);
Then the same out-of-bounds assert fires, now at cpref-taking path.
There is a similar trouble with "cprefs" array, that is declared as "short[]", handles "u2" elements, and yet again accessed as "short". Note that
This means we have a problem in 8u, but not anywhere else.
This is fairly easy to reproduce on the test case from
// The method can be NULL if the requested class version is gone
- Symbol* sym = (method != NULL) ? method->name() : holder->constants()->symbol_at(cpref);
+ Symbol* sym = holder->constants()->symbol_at(cpref);
Then the same out-of-bounds assert fires, now at cpref-taking path.
Attachments
Issue Links
- relates to
-
JDK-8194246 JVM crashes when calling getStackTrace if stack contains a method that is a member of a very large class
- Resolved
-
JDK-8140685 Fix backtrace building to not rely on constant pool merging
- Resolved