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

runtime/debug: TestStack fails when GOROOT_FINAL or GOROOT is not clean #62623

Open
lacombar opened this issue Sep 13, 2023 · 7 comments
Open
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@lacombar
Copy link
Contributor

lacombar commented Sep 13, 2023

[same environment as #62620]

$ cd src
$ GOROOT_FINAL=/final/destination/ ./all.bash

[...]
ok      runtime/coverage        0.003s
allocating objects
starting gc
starting dump
done dump
--- FAIL: TestStack (0.00s)
    stack_test.go:73: found GOROOT "/src/go" from environment; checking embedded GOROOT value
    stack_test.go:116: in line "\t/final/destination/src/runtime/debug/stack.go:24 +0x5e", expected prefix "\t/final/destination//src/runtime/debug/stack.go"
    stack_test.go:117: in line "\t/final/destination/src/runtime/debug/stack_test.go:31", expected prefix "\t/final/destination//src/runtime/debug/stack_test.go"
    stack_test.go:118: in line "\t/final/destination/src/runtime/debug/stack_test.go:34", expected prefix "\t/final/destination//src/runtime/debug/stack_test.go"
    stack_test.go:119: in line "\t/final/destination/src/runtime/debug/stack_test.go:56 +0x2c", expected prefix "\t/final/destination//src/runtime/debug/stack_test.go"
    stack_test.go:120: in line "\t/final/destination/src/testing/testing.go:1595 +0xff", expected prefix "\t/final/destination//src/testing/testing.go"
FAIL
FAIL    runtime/debug   0.073s
[...]

Notice the expected prefix' double path separator, /final/destination//src/, removing the trailing / from the environment variable works.

@bcmills bcmills added Testing An issue that has been verified to require only test changes, not just a test failure. compiler/runtime Issues related to the Go compiler and/or runtime. labels Sep 13, 2023
@bcmills
Copy link
Contributor

bcmills commented Sep 13, 2023

In general you need to set GOROOT_FINAL to a clean path.

That said, as of Go 1.21 there isn't much point in setting GOROOT_FINAL at all (see #62047).

@bcmills bcmills changed the title runtime/debug test fails due to unsanitized path runtime/debug test fails when GOROOT_FINAL is not clean Sep 13, 2023
@bcmills
Copy link
Contributor

bcmills commented Sep 13, 2023

I wonder, though: perhaps cmd/link should call filepath.Clean or similar on the value obtained from the environment?
(https://cs.opensource.google/go/go/+/master:src/cmd/link/internal/ld/pcln.go;l=813;drc=0460c61e5fd2242d27451f527dafc4d9a098fef4)

@bcmills bcmills added compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. and removed compiler/runtime Issues related to the Go compiler and/or runtime. Testing An issue that has been verified to require only test changes, not just a test failure. labels Sep 13, 2023
@prattmic
Copy link
Member

It couldn’t quite be filepath, right? A Linux build of the linker cross compiling for Windows would need to clean a Windows path. We need path/filepath/windows, etc.

@bcmills
Copy link
Contributor

bcmills commented Sep 14, 2023

In theory, yes.

In practice, I don't actually know how the embedded GOROOT value interacts with cross-compilation. 😅

@mknyszek mknyszek changed the title runtime/debug test fails when GOROOT_FINAL is not clean runtime/debug: TestStack fails when GOROOT_FINAL is not clean Sep 20, 2023
@mknyszek mknyszek added this to the Backlog milestone Sep 20, 2023
@cherrymui
Copy link
Member

I feel that the linker doesn't need to understand the meaning of GOROOT_FINAL. Could the go command clean it up before passing it to the linker?

@bcmills
Copy link
Contributor

bcmills commented Sep 20, 2023

At the moment cmd/go isn't doing anything to it unless -trimpath is set:
https://cs.opensource.google/go/go/+/master:src/cmd/go/internal/work/gc.go;l=649;drc=fbcf43c60ba5170309a238b0e42fd5879d419776
it just assumes that the linker will do something with whatever value is in the environment:
https://cs.opensource.google/go/go/+/master:src/cmd/go/internal/work/exec.go;l=1389-1395;drc=3857a89e7eb872fa22d569e70b7e076bec74ebbb

I agree that if we keep GOROOT_FINAL it would be reasonable for cmd/go to clean it up in the environment. (That would at least fix invocations via go build, although it would still leave a bit of a gap for cmd/link invocations via third-party build tools.)

@cherrymui
Copy link
Member

I wonder why we write "$GOROOT" at compile time and expand to the actual GOROOT at link time... I guess this may be useful previously when we had compiled .a files in GOROOT. If one moves GOROOT after compilation, those .a files are still valid. But now we don't have those .a files anymore. We probably could write the actual GOROOT (GOROOT_FINAL, if set) at compile time. Then we don't need to expand it in the linker. (We'd need to recompile if GOROOT_FINAL changes, previously we only need to relink. But that seems pretty minor.)

@cherrymui cherrymui changed the title runtime/debug: TestStack fails when GOROOT_FINAL is not clean runtime/debug: TestStack fails when GOROOT_FINAL or GOROOT is not clean Feb 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
Development

No branches or pull requests

5 participants