-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
cmd/compile: inline marker targets not reachable after assembly on ppc64x #40689
Comments
/cc @randall77 @laboger |
@mundaym I don't think the test in your CL is correct for ppc64x. If you look in cmd/compile/internal/ppc64/ggen.go function ginsop it is not generating a NOP but OR R0,R0,R0 for the inline marker. So this instruction won't get removed by PPC64 assembler and we shouldn't have the same problem as on S390x. Correction: I see where a NOP could be generated for an inlMark. I can make a change to stop removing NOPs in the assembler but I want to verify it's not leaving a lot of them. I'll have to read through the issue again because I'm not sure why this causes a hang and why no other platforms are hitting this problem? |
It's a tricky one to explain. I think of it as a 'use-after-free' bug:
The invalid inlining table data only appears to cause an infinite loop during traceback when the invalid PC value in the unscheduled It should be OK for the assembler to leave |
Change https://golang.org/cl/247842 mentions this issue: |
gopherbot please backport to 1.15 and 1.14. |
@laboger What are the effects of this bug? That is, why should the CL be backported? I can't quite figure out what the actual problem is here. Thanks. |
This is related to #40473. Tracebacks hang because inline marker information is corrupted. |
The change for s390x depends on this one. In the s390x fix, code was added to detect when the inline marker information was out of sync and that check fails on ppc64x. This change is needed to prevent that check from failing, as well as preventing other errors that could occur when they are out of sync. |
@gopherbot Please backport to 1.14 and 1.15 This bug can cause tracebacks to hang. There is no workaround. |
Backport issue(s) opened: #40766 (for 1.14), #40767 (for 1.15). Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases. |
Change https://golang.org/cl/248381 mentions this issue: |
It looks like issue #40473 also affects ppc64x based on this trybot run for CL 247697: https://storage.googleapis.com/go-build-log/8548211f/linux-ppc64le-buildlet_059f3c62.log. It should be relatively easy to fix with a code change similar to that done for s390x in CL 247697.
The text was updated successfully, but these errors were encountered: