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-8278309: [windows] use of uninitialized OSThread::_state #6734

Closed
wants to merge 3 commits into from

Conversation

tstuefe
Copy link
Member

@tstuefe tstuefe commented Dec 7, 2021

May I have reviews for this trivial fix.

On Windows, we use OSThread::_state in os::create_thread before it has been initialized. This causes an assert to fire in Thread::is_JavaThread_protected (assert(target->is_handshake_safe_for(current_thread))

This only happens if the following is true:

  • We log os=info level, thereby firing the "Thread started.." log output the parent thread of a newly started child thread writes. Since JDK-8268773, we also print the thread name. Thread::name() uses Thread::is_JavaThread_protected, but on Windows, the thread state has not been set yet.
  • This is an assert, so only debug, but in debug newly malloced memory is poisoned with "F1F1F1F1...", which hides the error since Thread::is_JavaThread_protected compares the thread state like this:
  if (target->osthread() == NULL || target->osthread()->get_state() <= INITIALIZED) {
    return true;
  }

and the compiler interprets the "F1F1F1F1" as a negative large value. Changing the init pattern to 0x01, or adding an explicit cast to unsigned, causes the assert to fire as soon as logging is switched on.


Musings:

I wondered whether we should change the thread state comparison to unsigned like this:

  if (target->osthread() == NULL || (unsigned)target->osthread()->get_state() <= INITIALIZED) {

which would have shown the error right away after JDK-8268773. This is matter of taste though since one could say that at this point we expect the enum to be filled correctly with one of its values, and guarding against uninitialized memory should belong somewhere else, maybe in a debug-only verify function.

--

Just my personal opinion, but OSThread could do with a bit of cleanup. E.g. using an initializer list to init its values, and possibly doing the per-platform-factoring out in a different way. That include-file-in-the-middle-of-class composition technique is terrible. It confuses IDEs and makes analyzing the code difficult, and the code is not really difficult in what it does.


Tests: GHAs (twice, once with experimentally set init word to 1 to see that the patch works)


Progress

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

Issue

  • JDK-8278309: [windows] use of uninitialized OSThread::_state

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/6734/head:pull/6734
$ git checkout pull/6734

Update a local copy of the PR:
$ git checkout pull/6734
$ git pull https://git.openjdk.java.net/jdk pull/6734/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 6734

View PR using the GUI difftool:
$ git pr show -t 6734

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/6734.diff

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Dec 7, 2021

👋 Welcome back stuefe! 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
Copy link

@openjdk openjdk bot commented Dec 7, 2021

@tstuefe 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 Dec 7, 2021
@tstuefe tstuefe force-pushed the osthread-uninitialized-member branch from b7058ef to e85638e Compare Dec 7, 2021
@tstuefe tstuefe marked this pull request as ready for review Dec 7, 2021
@openjdk openjdk bot added the rfr label Dec 7, 2021
@mlbridge
Copy link

@mlbridge mlbridge bot commented Dec 7, 2021

Webrevs

Copy link
Member

@dholmes-ora dholmes-ora left a comment

Looks good. :)

Thanks,
David

@openjdk
Copy link

@openjdk openjdk bot commented Dec 7, 2021

@tstuefe 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:

8278309: [windows] use of uninitialized OSThread::_state

Reviewed-by: dholmes, shade

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 39 new commits pushed to the master branch:

  • 5dcdee4: 8262341: Refine identical code in AddI/LNode.
  • b334d96: 8276964: Better indicate a snippet that could not be processed
  • 30f0c64: 8277992: Add fast jdk_svc subtests to jdk:tier3
  • 5266e7d: 8278379: Zero VM is broken due to UseRTMForStackLocks was not declared after JDK-8276901
  • e7db581: 8277168: AArch64: Enable arraycopy partial inlining with SVE
  • fb6d611: 8278276: G1: Refine naming of G1GCParPhaseTimesTracker::_must_record
  • d7ad546: 8276422: Add command-line option to disable finalization
  • ec7cb6d: 8276447: Deprecate finalization-related methods for removal
  • 3c2951f: 8275771: JDK source code contains redundant boolean operations in jdk.compiler and langtools
  • 3d61372: 8278363: Create extented container test groups
  • ... and 29 more: https://git.openjdk.java.net/jdk/compare/5045eb538b3afc6cf646642f1109473597b3004a...master

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 Dec 7, 2021
@tstuefe
Copy link
Member Author

@tstuefe tstuefe commented Dec 7, 2021

Looks good. :)

Thanks, David

Thank you David!

Copy link
Contributor

@shipilev shipilev left a comment

This looks fine as the limited fix.

But I do wonder if the initial state ALLOCATED should be stamped right in the OSThread::OSThread constructor. Also, I see other platforms, for example, Linux does:

  // set the correct thread state
  osthread->set_thread_type(thr_type);

  // Initial state is ALLOCATED but not INITIALIZED
  osthread->set_state(ALLOCATED);

Not sure how safe it is to add set_thread_type, but matching the comment for set_state is probably in order.

@tstuefe
Copy link
Member Author

@tstuefe tstuefe commented Dec 7, 2021

This looks fine as the limited fix.

But I do wonder if the initial state ALLOCATED should be stamped right in the OSThread::OSThread constructor.

Oh totally. This makes me itch. But I wanted a minimal patch to downport, and knowing me once I start touching OSThread I can't stop pulling threads. Ideally, I would like to get rid of OSThread altogether and merge it into Thread; there is no reason to have two physically separate structures like this.

Also, I see other platforms, for example, Linux does:

  // set the correct thread state
  osthread->set_thread_type(thr_type);

  // Initial state is ALLOCATED but not INITIALIZED
  osthread->set_state(ALLOCATED);

Not sure how safe it is to add set_thread_type, but matching the comment for set_state is probably in order.

Windows does not have a thread type. About the comment, sure, I can do that. Will do it before pushing.

Thanks, Thomas

Copy link
Member

@dholmes-ora dholmes-ora left a comment

The comment at line 783 could be tweaked to no longer say "Initially".

I think a simple follow up RFE could move ALLOCATED into the constructor as Aleksey suggested, without opening up the whole cleanup can of worms.

Thanks,
David

@tstuefe
Copy link
Member Author

@tstuefe tstuefe commented Dec 8, 2021

Okay, fixed the comment as David suggested. If no objections come forward, I'll push after breakfast.

@tstuefe
Copy link
Member Author

@tstuefe tstuefe commented Dec 8, 2021

/integrate

@openjdk
Copy link

@openjdk openjdk bot commented Dec 8, 2021

Going to push as commit 54993b1.
Since your change was applied there have been 40 commits pushed to the master branch:

  • 10e0318: 8278158: jwebserver should set request timeout
  • 5dcdee4: 8262341: Refine identical code in AddI/LNode.
  • b334d96: 8276964: Better indicate a snippet that could not be processed
  • 30f0c64: 8277992: Add fast jdk_svc subtests to jdk:tier3
  • 5266e7d: 8278379: Zero VM is broken due to UseRTMForStackLocks was not declared after JDK-8276901
  • e7db581: 8277168: AArch64: Enable arraycopy partial inlining with SVE
  • fb6d611: 8278276: G1: Refine naming of G1GCParPhaseTimesTracker::_must_record
  • d7ad546: 8276422: Add command-line option to disable finalization
  • ec7cb6d: 8276447: Deprecate finalization-related methods for removal
  • 3c2951f: 8275771: JDK source code contains redundant boolean operations in jdk.compiler and langtools
  • ... and 30 more: https://git.openjdk.java.net/jdk/compare/5045eb538b3afc6cf646642f1109473597b3004a...master

Your commit was automatically rebased without conflicts.

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

@openjdk openjdk bot commented Dec 8, 2021

@tstuefe Pushed as commit 54993b1.

💡 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
Labels
hotspot integrated
3 participants