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

8288483: JAVA_TOOL_OPTIONS are silently truncated if they exceed 1024 bytes #74

Closed
wants to merge 2 commits into from

Conversation

dsamersoff
Copy link

@dsamersoff dsamersoff commented Jun 15, 2022

The JAVA_TOOL_OPTIONS environment variable is used to pass additional JVM arguments.

The current implementation in jdk8 has an internal limit on the length of the option variable (1024 bytes) and the number of options (64).

A longer variable will be silently truncated and some options will be lost or the VM will exist with an unrecognized option error.

The fix is not a direct backport of the changes in the later JDKs, but I kept the code as close as possible to what we have in the latest jdk.

It's partial backport of relevant changes from JDK-8135195, JDK-8074895, JDK-8061999


Progress

  • Change must be properly reviewed (1 review required, with at least 1 Reviewer)
  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue

Issue

  • JDK-8288483: JAVA_TOOL_OPTIONS are silently truncated if they exceed 1024 bytes

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk8u-dev.git pull/74/head:pull/74
$ git checkout pull/74

Update a local copy of the PR:
$ git checkout pull/74
$ git pull https://git.openjdk.org/jdk8u-dev.git pull/74/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 74

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk8u-dev/pull/74.diff

Webrev

Link to Webrev Comment

@bridgekeeper
Copy link

bridgekeeper bot commented Jun 15, 2022

👋 Welcome back dsamersoff! 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 Pull request is ready for review label Jun 15, 2022
@mlbridge
Copy link

mlbridge bot commented Jun 15, 2022

Webrevs

Copy link
Member

@phohensee phohensee left a comment

Choose a reason for hiding this comment

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

Nit: in arguments.hpp, move the declaration or parse_arguments_buffer down 2 lines after parse_java_options_environment variable to match tip's relative placement.

Otherwise fine.

Copy link
Member

@phohensee phohensee left a comment

Choose a reason for hiding this comment

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

Lgtm.

@openjdk
Copy link

openjdk bot commented Jun 17, 2022

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

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

8288483: JAVA_TOOL_OPTIONS are silently truncated if they exceed 1024 bytes

Reviewed-by: phh

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

  • cd40350: Merge
  • 89aeae1: 8304053: Revert os specific stubs for SystemMetrics
  • ebbd3a8: 8303828: [Solaris] Broken jdk8u build after JDK-8266391
  • 5dc33f2: 8295530: Update Zlib Data Compression Library to Version 1.2.13
  • ca1c3b1: 8302791: Add specific ClassLoader object to Proxy IllegalArgumentException message
  • de0e5a2: 8152432: Implement setting jtreg @requires properties vm.flavor, vm.bits, vm.compMode
  • ae6405f: 8289301: P11Cipher should not throw out of bounds exception during padding
  • ad41d90: 8293232: Fix race condition in pkcs11 SessionManager
  • d6f8151: 8282600: SSLSocketImpl should not use user_canceled workaround when not necessary
  • a7fb08c: 8293815: P11PSSSignature.engineUpdate should not print debug messages during normal operation
  • ... and 244 more: https://git.openjdk.org/jdk8u-dev/compare/83e90957bef15267bed792ee5d8d65899a2487e8...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 Pull request is ready to be integrated label Jun 17, 2022
@bridgekeeper
Copy link

bridgekeeper bot commented Jul 15, 2022

@dsamersoff This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

@phohensee
Copy link
Member

/open

@openjdk
Copy link

openjdk bot commented Jul 15, 2022

@phohensee Only the pull request author can set the pull request state to "open"

@dsamersoff
Copy link
Author

/open

@openjdk
Copy link

openjdk bot commented Jul 16, 2022

@dsamersoff This pull request is already open

@bridgekeeper
Copy link

bridgekeeper bot commented Aug 13, 2022

@dsamersoff This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

@dsamersoff
Copy link
Author

/open

@openjdk
Copy link

openjdk bot commented Aug 13, 2022

@dsamersoff This pull request is already open

@jerboaa
Copy link
Contributor

jerboaa commented Sep 7, 2022

This seems a high-risk backport. As far as I can see it's not explained why it's needed. Especially why now? 8u has been around for some time without that fix. We cannot just backport everything.

@gnu-andrew
Copy link
Member

gnu-andrew commented Sep 8, 2022

I tend to agree with Severin here. Generally, enhancements shouldn't be backported.

Also, I don't see why this is being introduced under a new bug ID, and this is effectively hiding two enhancements inside a bug. The relevant fix for the 1024 limit is JDK-8135195, but that issue is referring to a limit on an options file, which is not supported in 8u, as it doesn't have JDK-8061999. This patch doesn't backport the options file support, so is effectively treading new ground in lifting the limit just for the environment variable, but with most of the code changes from the aforementioned bugs.

I think they may be a case for a simpler fix that improves os::getenv so it warns when the environment variable passed is greater than the buffer length (probably only when Verbose is on). However, I don't see the case mentioned in the title of this PR; the variable is not truncated, it is simply ignored in its entirety if it is too long ("The variable will be ignored if it exceeds the length of the buffer.")

From hotspot/src/os/linux/vm/os_linux.cpp:

bool os::getenv(const char* name, char* buf, int len) {
  const char* val = ::getenv(name);
  if (val != NULL && strlen(val) < (size_t)len) {
    strcpy(buf, val);
    return true;
  }
  if (len > 0) buf[0] = 0;  // return a null string                                                                                                         
  return false;
}

So os::getenv will return false, just as it would if the environment variable was not defined.

@dsamersoff
Copy link
Author

The main rationally behind these changes is to fix spec violation. JDK 8 specification does not set any limits for JAVA_TOOL_OPTIONS length and number of items, so every time when a customer steps into this problem, it gets escalated, and it is not possible to argue that this is the expected OpenJDK behavior.
This issue can happen, for example, when someone moves a setup with command line arguments pointing to a long path on the filesystem, or when moving an existing setup to buildpacks. From a regular user standpoint, the current behavior of simply skipping of some options leaves the user with unusable command line parameters. Worse, the user may not even notice that some options has been skipped.

Please look at the testcase https://github.com/dsamersoff/jdk_8288483_scratchpad/pull/2/files (this testcase is not a part of PR because it doesn’t exist in the upstream)

Codewise, the code is essentially the same to what we have in 11u with some minimal changes required to accommodate API difference.
The code in 11u is the result of several sequential changes that have been made under different CRs listed above. I chose to port the final code rather than come in with set of backports. But I can create a direct backport of code from jdk9 that was replaced later, if you think that it is less risky.

Please, look at https://github.com/dsamersoff/jdk_8288483_scratchpad/pull/1/files for difference between 11u (left) and what is proposed to 8u (right).

@bridgekeeper
Copy link

bridgekeeper bot commented Oct 7, 2022

@dsamersoff This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

@dsamersoff
Copy link
Author

/open

@openjdk
Copy link

openjdk bot commented Oct 14, 2022

@dsamersoff This pull request is already open

@bridgekeeper
Copy link

bridgekeeper bot commented Nov 11, 2022

@dsamersoff This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

@dsamersoff
Copy link
Author

/open

@openjdk
Copy link

openjdk bot commented Dec 7, 2022

@dsamersoff This pull request is already open

@bridgekeeper
Copy link

bridgekeeper bot commented Jan 4, 2023

@dsamersoff This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

@bridgekeeper
Copy link

bridgekeeper bot commented Feb 1, 2023

@dsamersoff This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the /open pull request command.

@bridgekeeper bridgekeeper bot closed this Feb 1, 2023
@dsamersoff
Copy link
Author

/open

@openjdk openjdk bot reopened this Feb 15, 2023
@openjdk
Copy link

openjdk bot commented Feb 15, 2023

@dsamersoff This pull request is now open

@bridgekeeper
Copy link

bridgekeeper bot commented Mar 17, 2023

@dsamersoff This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

@bridgekeeper
Copy link

bridgekeeper bot commented May 2, 2023

@dsamersoff This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the /open pull request command.

@bridgekeeper bridgekeeper bot closed this May 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready Pull request is ready to be integrated rfr Pull request is ready for review
4 participants