RFR: 8350111: [PPC] AsyncGetCallTrace crashes when called while handling SIGTRAP [v2]
Richard Reingruber
rrich at openjdk.org
Wed Feb 26 11:04:54 UTC 2025
On Wed, 26 Feb 2025 10:57:31 GMT, Richard Reingruber <rrich at openjdk.org> wrote:
>> With this change `JavaThread::pd_get_top_frame_for_profiling()` fails if the current thread is found to be `_thread_in_Java` but the CodeCache does not contain its pc.
>>
>> This will prevent crashes as described by the JBS item.
>>
>> The fix might be too conservative for situations where a thread doen't change its thread state when calling native code, e.g. using the Foreign Function & Memory API. The difficulty finding a less defensive fix is that one must detect if a valid pc can be found in the caller's ABI before constructing that frame.
>>
>> Testing:
>>
>> * DaCapo Tomcat with async-profiler on a fastdebug build.
>> * Tier 1-4 of hotspot and jdk on the main platforms and also on Linux/PPC64le and AIX.
>
> Richard Reingruber has updated the pull request incrementally with two additional commits since the last revision:
>
> - A frame isn't safe_for_sender if sender_pc() returns null
> - Revert first fix
>
> This reverts commit c4b81e2dc5a854efde8475d09b33b8f53dde987d.
I've pushed an alternative fix to consider a frame not `safe_for_sender` if its sender pc is null.
This of course avoids the assertion given in the bug.
As explained in the comment we might find other random values when looking for the sender pc if it hasn't been stored to stack yet. This has to be handled by subsequent consistency checks.
Let's see how the nightly testing goes...
-------------
PR Comment: https://git.openjdk.org/jdk/pull/23641#issuecomment-2684636597
More information about the hotspot-runtime-dev
mailing list