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: corrected issue11656 test fails on ppc64 and mips #43283

Closed
ianlancetaylor opened this issue Dec 19, 2020 · 6 comments
Closed

runtime: corrected issue11656 test fails on ppc64 and mips #43283

ianlancetaylor opened this issue Dec 19, 2020 · 6 comments

Comments

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Dec 19, 2020

In https://golang.org/cl/278473 I corrected $GOROOT/test/fixedbugs/issue11656.go to actually test what it was trying to test: executing a trap instruction at a PC value larger than zero. That fix caused the test to fail on:

In each case the test failed reporting runtime: unknown pc, which is more or less what the CL in #11656 was supposed to fix.

For now I'm going to skip the tests for these targets.

@gopherbot
Copy link

@gopherbot gopherbot commented Dec 19, 2020

Change https://golang.org/cl/279312 mentions this issue: test: skip issue11656.go on mips/mips64/ppc64

gopherbot pushed a commit that referenced this issue Dec 21, 2020
For #11656
For #43283

Change-Id: I1fcf2b24800f421e36201af43130b487abe605b1
Reviewed-on: https://go-review.googlesource.com/c/go/+/279312
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
@laboger
Copy link
Contributor

@laboger laboger commented Dec 21, 2020

Why does this apply to ppc64 but not ppc64le?

@ianlancetaylor
Copy link
Contributor Author

@ianlancetaylor ianlancetaylor commented Dec 21, 2020

@laboger I don't know. I haven't looked into it.

@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented Dec 21, 2020

I think what happens is that on machines that the test passes, it faults with SIGSEGV (or maybe SIGBUS) at the CALL instruction when it is jumping to fn, because that address is not executable. On machines that this fails, it actually jumped to fn and executed the trap instruction (somehow the kernel allowed to execute that address), and faulted with SIGTRAP, where it failed to unwind, because the PC doesn't match any function.

It might be possible to do something for better traceback, for example, if the PC is not in any known function, maybe use the LR? Assume the frame size is 0 and hope for the best? Not sure...

Why does this apply to ppc64 but not ppc64le?

Perhaps the kernel on the AIX builder allows execution on that address whereas the Linux/PPC64LE builder doesn't.

@laboger
Copy link
Contributor

@laboger laboger commented Dec 21, 2020

I think the test only needs to be disabled on aix-ppc64, but it is disabled for aix-ppc64 and linux-ppc64. The failure log posted above is from aix-ppc64. Not a big deal, I just didn't understand why linux-ppc64 and linux-ppc64le would behave differently for this case.

@gopherbot
Copy link

@gopherbot gopherbot commented Dec 21, 2020

Change https://golang.org/cl/279423 mentions this issue: test: trigger SIGSEGV instead of SIGTRAP in issue11656.go

@gopherbot gopherbot closed this in c06a354 Dec 22, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants