RFR: 8339307: jhsdb jstack could not trace FFM upcall frame [v4]

Yasumasa Suenaga ysuenaga at openjdk.org
Mon Sep 2 14:52:21 UTC 2024


On Mon, 2 Sep 2024 11:59:01 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> I understand that adding the UpcallStub type to the SA agent code makes the WrongTypeException go away, and then we run into an assertion failure because the frame size is zero?

Yes.

> Note how there is also special handling for (JNI) entry frames in the SA.

Do you mean `JavaCallWrapper` (`X86Frame::senderForEntryFrame` in SA) ?

> I'm guessing because we end up walking the native frames until we get back to Java, and the native frames are simply ignored. I'm not sure if that will always work for arbitrary native code though.
> 
> I think the right fix here is to implement handling for upcall stub frames in the SA agent, since that's also how entry frames are handled. I don't think setting the frame size in hotspot is actually needed if we do that.

If we add some frame info (return address and FP) like `JavaCallWrapper` to `UpcallStub` and process it in SA, we do not need frame size of `UpcallStub` as you said. But I think it should be fixed in all of upcall implementation.
`UpcallStub` is "Stub", so it compliant native calling convention. Thus I believe native frame unwinder like `X86Frame` should always work if frame size is set in `UpcallStub`.

We need to fix all of upcall implementation in both case, and zero frame size is not nature. In addition adding frame size is simpler than add special handling for `UpcallStub` and SA. Thus I give +1 to add frame size to `UpcallStub`.

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

PR Comment: https://git.openjdk.org/jdk/pull/20789#issuecomment-2324921013


More information about the serviceability-dev mailing list