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

Daniel D.Daugherty dcubed at openjdk.java.net
Tue Jan 4 20:55:16 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?

I don't think the safepoint poll is coming thru this code path. I ran this fix
through Mach5 Tier[1-6] and did not see any failures caused by hitting
a `ShouldNotReachHere()` call. It's hard to imagine that Tier[1-6] testing
wouldn't exercise the safepoint polling code paths.

I've also verified that the Parfait tool no longer issues the complaints.

I will poke around and see if I can determine what the safepoint polling
is doing.

> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 293:
> 
>> 291: 
>> 292: address MacroAssembler::target_addr_for_insn_allow_null_ret(address insn_addr, unsigned insn) {
>> 293:   if (Instruction_aarch64::extract(insn, 31, 22) == 0b1011100101 &&
> 
> Consider replacing raw constants check with NativeInstruction::is_ldrw_to_zr function call which performs the same check.

Good catch. There are actually two uses of the raw constants in
macroAssembler_aarch64.cpp and I've cleaned up both.

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

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


More information about the hotspot-runtime-dev mailing list