-
Bug
-
Resolution: Fixed
-
P3
-
openjdk8u272
-
b01
-
generic
-
generic
There is a bug in JFR backport (although inspired by flawed design of ClassFileParser). ClassFileParser instance is holding a pointer to ClassFileStream even if it is created by parseClassFile(). But parseClassFile() has a ResourceMark so this instance is deleted immediately upon return from parseClassFile(). The instance is created when data is overriden by JVMTI callback (e.g. when using java agent instrumentation).
At the same time the reference to ClassFileStream instance is used by JFR code outside of parseClassFile if the class being loaded is JFR event class (jdk/jfr/Event or subclass)
So effectively attempt to transform any JFR event class results in accessing dead memory. in slowdebug build this immediately crashes because this memory is zapped by ~ResourceMark. Product builds may or may not crash depending on particular circumstances
IMHO this is not strictly JFR backport bug since it's provoked by leaking reference to dead object from parseClassStream() even though the actual crash did not happen until JFR backport was integrated. So it's better to fix it by more consistent use of ResourceMarks around calls to ClassFileParser::parseClassFile (some of the callers put their own ones, but some are not)
At the same time the reference to ClassFileStream instance is used by JFR code outside of parseClassFile if the class being loaded is JFR event class (jdk/jfr/Event or subclass)
So effectively attempt to transform any JFR event class results in accessing dead memory. in slowdebug build this immediately crashes because this memory is zapped by ~ResourceMark. Product builds may or may not crash depending on particular circumstances
IMHO this is not strictly JFR backport bug since it's provoked by leaking reference to dead object from parseClassStream() even though the actual crash did not happen until JFR backport was integrated. So it's better to fix it by more consistent use of ResourceMarks around calls to ClassFileParser::parseClassFile (some of the callers put their own ones, but some are not)