-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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: frame pointer check fails on arm64 for C-to-Go calls #59401
Comments
EDIT: Whoops, I just saw who posted this. 😅 |
I think there are two ways we could address this:
I think it would be good to start with the first option. Right now we don't use frame pointer unwinding for execution tracing if there are C calls on the stack, specifically because of this kind of problem. We could follow that pattern for future uses of frame pointer unwinding internally (e.g. #16638). And in that case, we know that We could consider the second option in the future. It would probably be worth a little more discussion, though. For example, if we wanted to be able to use frame pointer unwinding even with C frames on the stack, we'd still want a way to take advantage of |
Have you considered changing asmcgocall/cgocallback so they save on the stack, instead of BP, the value of |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Ran the
TestCgoTracebackGoroutineProfile
test withdebugCheckBP
enabled on an arm64 machine.What did you expect to see?
The test to pass.
What did you see instead?
The test fails:
With additional stack debug logging turned on, I see that the check fails when visiting the
runtime.cgocallbackg
frame:Debug logging output
It appears that the
runtime.cgocall
assembly routine attempts to put a frame pointer on the Go stack when switching to it. But from this test failure, it seems like we're getting the wrong frame pointer? Possibly an address on the C stack (when the thread is created by C rather than by the runtime)?The text was updated successfully, but these errors were encountered: