RFR: 8371368: SIGSEGV in JfrVframeStream::next_vframe() on arm64 [v2]

[Aleksey Shipilev]

On Tue, 18 Nov 2025 14:46:25 GMT, Markus Grönlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> Please see a description in the JIRA ticket about this problem related to PreserveFramePointer on arm64.
>> 
>> Summary:
>> The third argument passes the sender_sp as the frame FP - which is valid for most situations where unextended_sp() + cb->frame_size() is used (a compiled frame's real_fp() is usually equivalent to the sender SP). But this is incorrect when PreserveFramePointer is set. To fix this, a real frame pointer must be passed to the constructor.
>> 
>> Testing: jdk_jfr, stress testing
>> 
>> Thanks
>> Markus
>
> Markus Grönlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ppc and s390 do not have frame::sender_sp_offset defined

src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 220:

> 218:           if (is_valid(pc_desc)) {
> 219:             intptr_t* const synthetic_sp = sender_sp - sampled_nm->frame_size();
> 220:             top_frame = frame(synthetic_sp, synthetic_sp, sender_sp - 2, pc_desc->real_pc(sampled_nm), sampled_nm);

Hold on. I am looking at relevant constructor:


inline frame::frame(intptr_t* sp)
  : frame(sp, sp,
          *(intptr_t**)(sp - frame::sender_sp_offset),
          pauth_strip_verifiable(*(address*)(sp - 1))) {}


...and:


inline intptr_t* frame::fp(const intptr_t* sp) {
  assert(sp != nullptr, "invariant");
  return reinterpret_cast<intptr_t*>(sp[-2]);
}


So `sender_sp - 2` (which I think is `sp - frame::sender_sp_offset`?) is the _location_ for the FP, not the FP itself?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28373#discussion_r2541567391