JDK-8259843: initialize dli_fname array before calling dll_address_to_library_name

[MBaesken]

On some platforms like bsd/mac, we call dll_address_to_library_name with a buffer parameter (e.g. char dli_fname[MAXPATHLEN]; ) that has uninitialized content.
This is usually no problem because dll_address_to_library_name fills the array, but on some codepaths it seems not to be the case.

See also this related sonar issue :
https://sonarcloud.io/project/issues?id=jdk&open=AXaE0drk8L9hkQskGEXZ&resolved=false&types=BUG

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed

Issue

• JDK-8259843: initialize dli_fname array before calling dll_address_to_library_name

Reviewers

• Lutz Schmidt (@RealLucy - Reviewer)
• David Holmes (@dholmes-ora - Reviewer)

Download

$ git fetch https://git.openjdk.java.net/jdk pull/2144/head:pull/2144
$ git checkout pull/2144

[bridgekeeper]

👋 Welcome back mbaesken! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@MBaesken The following label will be automatically applied to this pull request:

• hotspot

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 00: Full (8c47265)

[RealLucy]

The changes look good to me.
linuxppcle build error unrelated. Addressed by JDK-8259978.

[openjdk]

@MBaesken This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8259843: initialize dli_fname array before calling dll_address_to_library_name

Reviewed-by: lucy, dholmes

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 9 new commits pushed to the master branch:

• cf25383: Merge
• f7b96d3: 8259796: timed CompletableFuture.get may swallow InterruptedException
• a37cd5a: 8259859: Missing metaspace NMT memory tag
• 33dcc00: 8132984: incorrect type for Reference.discovered
• 3edf393: 8259978: PPC64 builds broken after JDK-8258004
• 5d8861b: 8259995: Missing comma to separate years in copyright header
• 5cfb36e: 8259036: Failed JfrVersionSystem invariant when VM built with -fno-elide-constructors
• c0e9c44: 8259962: Shenandoah: task queue statistics is inconsistent after JDK-8255019
• 82adfb3: 8134540: Much nearly duplicated code for PerfMemory support

Please see this link for an up-to-date comparison between the source branch of this pull request and the master branch.
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[dholmes-ora]

Hi Matthias,

Seems okay. One query below.

Thanks,
David

[dholmes-ora]

Can this not just be an assert: buf != NULL && buflen > 0 ?

[MBaesken]

Hi David, I think a return would be clearer but an assert is "better than nothing" .

Best regards, Matthias

[RealLucy]

With an assert, you assume this is a "cannot occur error". You should be pretty sure to have good test coverage to find all "illegal invocations" before letting a release build escape into the wild.

[tstuefe]

+1 for the assert.
If you are worried about release, combine assert with release check:

assert(buf && buflen > 1, "sanity");
if (buf == NULL || buflen < 1) return;

Its what I usually do if I want to be super thorough.
Sorry for the bikeshedding :)

[MBaesken]

Hi Thomas, I like your suggestion ; David are you fine with it ?

[mlbridge]

Mailing list message from David Holmes on hotspot-dev:

On 20/01/2021 6:32 pm, Lutz Schmidt wrote:

On Wed, 20 Jan 2021 08:21:36 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

src/hotspot/share/runtime/frame.cpp line 543:

541: bool found;
542:
543: if (buf == NULL || buflen < 1) return;

Can this not just be an assert: buf != NULL && buflen > 0 ?

Hi David, I think a return would be clearer but an assert is "better than nothing" .

Best regards, Matthias

With an assert, you assume this is a "cannot occur error". You should be pretty sure to have good test coverage to find all "illegal invocations" before letting a release build escape into the wild.

The problem with a return is that it implies these conditions are
allowable and could reasonably happen, when in fact it would be an
internal programming error in the VM. Do we have test coverage for all
the code paths involved? Probably not. But the vast majority of
assertions in the VM do not have a "release" bail-out path. Keeping one
here is unnecessary and overkill IMO but I won't insist it be removed as
this is essentially error reporting code anyway.

David

[MBaesken]

/integrate

[openjdk]

@MBaesken Since your change was applied there have been 15 commits pushed to the master branch:

• 52ed2aa: 8259786: initialize last parameter of getpwuid_r
• 70b5b31: 8257664: HTMLEditorKit: Wrong CSS relative font sizes
• 0b01d69: 8260005: Shenandoah: Remove unused AlwaysTrueClosure in ShenandoahConcurrentRootScanner::roots_do()
• 0529480: 8259867: Move encoding checks into ZipCoder
• 7c32ffe: 8258383: vmTestbase/gc/g1/unloading/tests/unloading_compilation_level[1,2,3] time out without TieredCompilation
• 9f21bb6: 8259983: do not use uninitialized expand_ms value in G1CollectedHeap::expand_heap_after_young_collection
• cf25383: Merge
• f7b96d3: 8259796: timed CompletableFuture.get may swallow InterruptedException
• a37cd5a: 8259859: Missing metaspace NMT memory tag
• 33dcc00: 8132984: incorrect type for Reference.discovered
• ... and 5 more: https://git.openjdk.java.net/jdk/compare/a9519c83b8f118f62190a3956fca6c45387c7d6b...master

Your commit was automatically rebased without conflicts.

Pushed as commit 69f90b5.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.