Skip to content

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

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.

Sign up for GitHub

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

Jump to bottom
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
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Go1.17

Comments

@ianlancetaylor
Copy link
Member

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.
@ianlancetaylor ianlancetaylor added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Dec 19, 2020
@ianlancetaylor ianlancetaylor added this to the Go1.17 milestone Dec 19, 2020
@gopherbot
Copy link
Contributor

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
@ianlancetaylor
test: skip issue11656.go on mips/mips64/ppc64
9abbe27 
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 commented Dec 21, 2020

Why does this apply to ppc64 but not ppc64le?

@ianlancetaylor
Copy link
Member Author

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

@cherrymui
Copy link
Member

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 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
Contributor

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

@golang golang locked and limited conversation to collaborators Dec 22, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Go1.17
Development

No branches or pull requests
4 participants
@ianlancetaylor @gopherbot @laboger @cherrymui