On Tue, 2 Dec 2025 08:19:32 GMT, Marc Chevalier <[email protected]> wrote:
> Seems that it was just [JDK-8367151: [lworld] CorrectlyRestoreRfp.java > triggers "bad oop found" during > deoptimization](https://bugs.openjdk.org/browse/JDK-8367151)/https://github.com/openjdk/valhalla/pull/1751. > When I checked first if it still reproduces, > https://github.com/openjdk/valhalla/pull/1751 wasn't integrated yet. And > after investigation, it turned out to be the same issue. And after > integration of the said PR, the problem didn't show again under much more > extensive testing than what was enough to reproduce before. > > In more details, the case I investigated was mostly in `test76_verifier` > (occasionally in `test78_verifier`) > https://github.com/openjdk/valhalla/blob/acb511a9f5c7b750b41e1ce77aab3d1a59613097/test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestNullableArrays.java#L2100-L2120 > > that is C1-compiled. During a call to C2-compiled `verify`: > https://github.com/openjdk/valhalla/blob/acb511a9f5c7b750b41e1ce77aab3d1a59613097/test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestNullableArrays.java#L1145-L1153 > > an oop is passed in rfp. Sometimes, the GC moves the object during the > execution of `verify`, it updated the wrong copy of RFP on the stack. Then > `verify` hits an uncommon trap, and in the process picks the wrong `rfp` by > exactly the same mechanism as in > [JDK-8367151](https://bugs.openjdk.org/browse/JDK-8367151). Later in > `test76_verify`, the content of rfp, that now contains a wrong oop, is used, > garbage is read, segfault. > > The fact that is goes through an uncommon trap makes it a slightly different > flavor than what I've seen before. Also, I should have taken my own advice, > and use SerialGC, it would have saved me some complications! > > I suggest we just un-problem list now. > > Thanks, > Marc Thanks! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1766#issuecomment-3605613746
