8303427: Fixpath confused if unix root contains "/jdk"

[erikj79]

On Windows, when a directory exists in the "unix" root with the same name as a directory in the "test" dir, fixpath will corrupt test arguments to jtreg (and possibly other arguments as well). Fixpath sees a string like this:

test/jdk/foo

It looks for the first / and checks if the first element following that, until the next /, is an existing directory in the unix filesystem root. In this case, the reporter had a directory named "/jdk" which satisfies this heuristic check. This makes fixpath assume that the /jdk/foo part is an absolute unix path that needs to be rewritten to a Windows path.

My suggested fix is to look at the prefix part, "test" in this case, and see if that itself is a valid path in the current working directory, as that would indicate that the string is intended to be a relative path.

I think we also need to account for possible prefixes with : and = here to handle a string like:

jtreg:test/jdk/foo

In that case we need to remove anything up to the last : before we try to match it as a relative directory. (Same thing applies to =)

Changing the heuristics of fixpath is rather sensitive and risky. I would appreciate help from people using Windows with trying this patch with some of your regular workflows.

---

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-8303427: Fixpath confused if unix root contains "/jdk" (Bug - P4)

Reviewers

• Mikael Vidstedt (@vidmik - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/15461/head:pull/15461
$ git checkout pull/15461

Update a local copy of the PR:
$ git checkout pull/15461
$ git pull https://git.openjdk.org/jdk.git pull/15461/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 15461

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/15461.diff

Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back erikj! 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]

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

• build

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 (20e1fd63)

[TheShermanTanker]

The GitHub Actions failures look terrifying, but all of them are just a failing JTReg download for some reason (Not related to the change). Will recompile with this change and report back as soon as I can

[TheShermanTanker]

Works normally on both master and the experimental JDK-8288293 branch

[erikj79]

The GitHub Actions failures look terrifying, but all of them are just a failing JTReg download for some reason (Not related to the change). Will recompile with this change and report back as soon as I can

I hit rerun and it seems have worked

Works normally on both master and the experimental JDK-8288293 branch

Thank you for testing! I'm still running through more scenarios.

[erikj79]

I have done a lot of testing and comparison builds so I'm feeling pretty confident about this patch now. Does anyone dare reviewing?

[vidmik]

Just because I'm curious: in which cases would the prefix contain = (equals)?

[openjdk]

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

8303427: Fixpath confused if unix root contains "/jdk"

Reviewed-by: mikael

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

• c8acab1: 8315413: Remove special filtering of Continuation.yield0 in StackWalker
• ea5aa61: 8315383: jlink SystemModulesPlugin incorrectly parses the options
• 29ff1e4: 8315445: 8314748 causes crashes in x64 builds
• 145d8bc: 8315051: jdk/jfr/jvm/TestGetEventWriter.java fails with non-JVMCI GCs
• 486fa08: 8313873: java/nio/channels/DatagramChannel/SendReceiveMaxSize.java fails on AIX due to small default RCVBUF size and different IPv6 Header interpretation
• b0353ad: 8315242: G1: Fix -Wconversion warnings around GCDrainStackTargetSize
• b594f01: 8314748: 1-10% regressions on Crypto micros
• 39f1813: 8315318: Typo in comment on sun.nio.ch.Net.unblock4
• 47aa6f3: 8315219: G1: Improve allocator pathological case where it keeps doing direct allocations instead of retiring a PLAB
• 218829e: 8315421: [BACKOUT] 8314834 serviceability/jdwp/AllModulesCommandTest.java ignores VM flags
• ... and 39 more: https://git.openjdk.org/jdk/compare/99ea8bf2b962011e57d02a93217d65d7259e8f80...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.

[erikj79]

Just because I'm curious: in which cases would the prefix contain = (equals)?

I don't have a concrete example, but one could imagine a command taking make or configure style variable arguments like this:

$ fixpath exec some/windows/command foo=/some/absolute/path

The existing logic was already handling both : and = together, so I figured it would be consistent.

[erikj79]

/integrate

[openjdk]

Going to push as commit 2f7c65e.
Since your change was applied there have been 68 commits pushed to the master branch:

• e9e0c56: 8314319: LogCompilation doesn't reset lateInlining when it encounters a failure.
• 56b8db1: 8258970: Disabled JPasswordField foreground color is wrong with GTK LAF
• 0d4cadb: 8315195: RISC-V: Update hwprobe query for new extensions
• b4f7069: 8315446: G1: Remove unused G1AllocRegion::attempt_allocation
• cf02cf3: 8315098: Improve URLEncodeDecode microbenchmark
• c32e340: 8315321: [aix] os::attempt_reserve_memory_at must map at the requested address or fail
• 42f5b9e: 8315436: HttpsServer does not send TLS alerts
• 033f311: 8315069: Relativize extended_sp in interpreter frames
• c2e01eb: 8313983: jmod create --target-platform should replace existing ModuleTarget attribute
• 81b5d22: 8315459: Print G1 reserved and committed sizes as separate items in VM.info and hs_err
• ... and 58 more: https://git.openjdk.org/jdk/compare/99ea8bf2b962011e57d02a93217d65d7259e8f80...master

Your commit was automatically rebased without conflicts.

[openjdk]

@erikj79 Pushed as commit 2f7c65e.

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

[magicus]

Some post-checkin reflections: I think this looks sane. In the end, we're doing a fair bit of guesswork to identify the paths, but this seems like a reasonable addition to the guessing machinery.

If I recall correctly, one thing that really made this even more messed-up was that on Windows, you could have like buildtool.exe /pathOpt/jdk/src/..., which needed to be rewritten as buildtool.exe /pathOptC:\jdk\src\.... Hence the whole "prefix" dance.

With this change, if the user has a directory named pathOpt in the unix root, we will do the wrong thing. Otoh, if that were the case, we'd be screwed anyway since there would be no way for us to separate a proper reference to files in /pathOpt and an argument beginning with /pathOpt.

We have tried to minimize the risk of this by using - instead of / as option start marker on Windows as well as on unices, but there are likely places where a slash has slipped by, or where the command line is created by external tools outside our control.