Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JDK-8259843: initialize dli_fname array before calling dll_address_to_library_name #2144

Closed
wants to merge 1 commit into from

Conversation

@MBaesken
Copy link
Member

@MBaesken MBaesken commented Jan 19, 2021

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

Download

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

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Jan 19, 2021

👋 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 openjdk bot added the rfr label Jan 19, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Jan 19, 2021

@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.

@openjdk openjdk bot added the hotspot label Jan 19, 2021
@mlbridge
Copy link

@mlbridge mlbridge bot commented Jan 19, 2021

Webrevs

Copy link
Contributor

@RealLucy RealLucy left a comment

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

@openjdk
Copy link

@openjdk openjdk bot commented Jan 19, 2021

@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.

@openjdk openjdk bot added the ready label Jan 19, 2021
Copy link
Member

@dholmes-ora dholmes-ora left a comment

Hi Matthias,

Seems okay. One query below.

Thanks,
David

@@ -540,9 +540,11 @@ void frame::print_C_frame(outputStream* st, char* buf, int buflen, address pc) {
int offset;
bool found;

if (buf == NULL || buflen < 1) return;
Copy link
Member

@dholmes-ora dholmes-ora Jan 20, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

@MBaesken MBaesken Jan 20, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Best regards, Matthias

Copy link
Contributor

@RealLucy RealLucy Jan 20, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

@tstuefe tstuefe Jan 20, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+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 :)

Copy link
Member Author

@MBaesken MBaesken Jan 20, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@mlbridge
Copy link

@mlbridge mlbridge bot commented Jan 20, 2021

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
Copy link
Member Author

@MBaesken MBaesken commented Jan 20, 2021

/integrate

@openjdk openjdk bot closed this Jan 20, 2021
@openjdk openjdk bot added integrated and removed ready rfr labels Jan 20, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Jan 20, 2021

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
4 participants