RFR: 8282306: os::is_first_C_frame(frame*) crashes on invalid link access [v9]

[Johannes Bechberger]

On Sat, 26 Feb 2022 06:02:45 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix tests
>
> src/hotspot/share/runtime/os.cpp line 1184:
> 
>> 1182: #ifdef _WINDOWS
>> 1183:   return true; // native stack isn't walkable on windows this way.
>> 1184: #else
> 
> This change has nothing to do with the bug.
> 
> I would leave this as it is and let the code below at least compile on windows. Then we know it does not bitrot there. I am also not clear why this would not work on windows, since we could optionally build with framepointers enabled, right? And don't we have frame pointers on 32-bit windows always? I may remember this wrong.

There is a special function on windows to obtain native stack traces, it uses an OS function

> test/hotspot/gtest/runtime/test_os.cpp line 874:
> 
>> 872:   frame invalid_frame;
>> 873:   EXPECT_TRUE(os::is_first_C_frame(&invalid_frame)); // the frame has zeroes for all values
>> 874: 
> 
> Please add a test with valid looking but garbage pointers, to test that your safefetch really works. We usually do this by reserving + protecting a stripe of memory and using that one as guaranteed faulting pointer.

I thought about, but was unsure how to it properly.

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

PR: https://git.openjdk.java.net/jdk/pull/7591