[jdk18] RFR: 8272058: 25 Null pointer dereference defect groups in 4 files [v2]

Daniel D.Daugherty dcubed at openjdk.java.net
Tue Jan 4 21:41:11 UTC 2022


On Fri, 24 Dec 2021 08:09:48 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8272058
>>  - 8272058.exp1.patch
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 286:
> 
>> 284:                    + (uint64_t(Instruction_aarch64::extract(insns[1], 20, 5)) << 16)
>> 285:                    + (uint64_t(Instruction_aarch64::extract(insns[2], 20, 5)) << 32));
>> 286:   } else if (Instruction_aarch64::extract(insn, 31, 22) == 0b1011100101 &&
> 
> It must be a check for safePoint poll: ldrw zr, polling_page. Technically, the target address for this instruction is zero and the function is correct. I am not sure Parfait is right in his complaints. After all, does this code ever works? That is, if you remove it, will the SholdNotReachHere below fire?

@bulasevich - I've made another pass through the code and checked the
calls to `MacroAssembler::target_addr_for_insn()` and I don't see any of
those calls in areas related to safepoint polling. From the other POV, I
took a look at the aarch64 safepoint polling code and I don't see a way
into `MacroAssembler::target_addr_for_insn()` .

It is entirely possible that I'm missing something here and would appreciate
it if you could sanity check my conclusions here.

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

PR: https://git.openjdk.java.net/jdk18/pull/51


More information about the hotspot-runtime-dev mailing list