runtime: panic leaves memory in unpredictable state #1304
Labels
Milestone
Comments
What does "happen before" exactly mean? http://groups.google.com/group/golang-nuts/browse_thread/thread/1e63592fe6eef803 |
This is an implementation error. The language spec clearly says that a division by zero acts the same as a direct call to panic ( http://golang.org/doc/go_spec.html#Run_time_panics ). This is a single-threaded program; the main function does start only after any initialization thread has terminated. The results should be 2. Labels changed: added priority-low, removed priority-medium. Status changed to Accepted. |
There are two possible fixes. One is to flush global writes before doing anything that might panic, such as dereferencing a pointer or dividing. The other is to record enough information that the trap handler can flush the registers back to their global variable destinations. We plan to do one of them eventually. Owner changed to r...@golang.org. Status changed to LongTerm. |
|
Owner changed to builder@golang.org. |
|
This issue was closed by revision 8998835. Status changed to Fixed. |
CL https://golang.org/cl/97500044 mentions this issue. |
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
As Mikael Tillenius reported in the mailing list, runtime panics may leave global variables in an unpredictable state. The following program, for instance, will print "a = 1", rather than most expected "a = 2". package main var a = 1 func main() { defer func() { recover() println("a =", a) }() a = 2 a = a/0 a = 3 } As a consequence, even if panics are recovered, when there is interaction with global variables, they may leave the system in an unpredictable state. Due to the nature of the problem, not even synchronization primitives will make the behavior predictable. At the very least, the issue should be documented in the specification and memory model.The text was updated successfully, but these errors were encountered: