You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I expected to be able to see at least one of the input arguments to the crashing function Square() as they are still live. At the point of the crash, the RAX register used to pass the first parameter has been clobbered, but its state gives valuable input about what the original value of the first parameter was. The second parameter can be found in RBX untouched.
The disassembly is as follows (truncated, annotated):
I expected that the parameter values in the stack trace would be as accurate as they could be, or at least more accurate than they are now. Now they contain values that aren't in any way related to the code that was running. The signal handler (likely) clobbers the registers state, which is why I believe we see values like 0x4046d9?, 0x60?, 0x0?. We can see the same values if we call panic() manually.
I've been told it would be a more involved project to improve the stack printer in such a way that it could take into account (better) the liveness, clobber state et cetera to get the "best possible estimate" for the parameter value. But a cheaper solution that would serve well in the interim would be to just dump the register state (all registers) when handling a crash. Then, a crash investigator can combine this information with an objdump to figure out whatever possible about the state of the crashing stack.
An argument raised was that dumping register state would be scary to users. Some counterpoints:
Go already dumps registers when there is a fatal error in the runtime. I don't see why user panics should be different.
When Go 1.17 introduced the regabi, the debugging experience for stack traces was weakened by the values being incorrect fairly often. It used to be that register state wasn't quite so necessary because previously to Go 1.17 the parameters were generally correct. This change would improve the situation a bit again.
The expected user of a stack trace is a developer, who may benefit from some insight into the computing stack. Even if the developer who first looks at the crash does not have the required experience to extract useful information, they may reroute that to an expert who can use it. If the register state is not printed as is currently the case, no-one can help.
C++ crash handlers at the place I work always print the register state (but no arguments), and anecdotally (for me) it has been useful in the past.