RFR: 8325153: SEGV in stackChunkOopDesc::derelativize_address(int)

[Coleen Phillimore]

On Wed, 21 Feb 2024 09:21:11 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> The JVM used to SEGV when running jdk/internal/vm/Continuation/Fuzz.java with '-Xlog:all=trace:file=hotspot.%p.log'
> 
> The problem was this line in StackWalk::fetchNextBatch() at src/hotspot/share/prims/stackwalk.cpp:547:
> 
> log_debug(stackwalk)("advanced past %s", stream.method()->external_name());
> 
> It is not always safe to dig out the name of the last frame here. The second batch is resource allocated on top of the first batch, so there is no crash when we dig out the last name from the first batch. However the third batch, is resource allocated on the same stack level as the second, which means that the second batch has been reclaimed. Thus trying to reach into the second batch when processing the third will cause a segmentation violation.
> 
> Now passes:
> jdk/internal/vm/Continuation/Fuzz.java with '-Xlog:all=trace:file=hotspot.%p.log'
> As well as tier1-tier5

src/hotspot/share/prims/stackwalk.cpp line 551:

> 549:       // have been reclaimed by HandleMark::pop_and_restore() together
> 550:       // with the rest of the previous batch.
> 551:       log_debug(stackwalk)("advanced past last frame decoded in the previous batch");

Your description says ResourceMark but this comment says HandleMark.  Stream is native memory allocated as a secret field of the frames_array somewhere (resource allocated?), and frames_array is a Handle subject to HandleMark.  I don't understand which got deallocated with this comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17942#discussion_r1497737210