The same timing problem that is exposed by issue #369 can cause a crash if the order in which GoMove objects are deallocated is changed.
Here is a similar schema as in #369, but with a different timing:
The system creates two moves
+---next------+
| v
move1 move2a
^ |
+---previous--+
The system discards move2a, but the GoMove object is not immediately deallocated.
The system creates move2b that replaces move2a.
move2a still has the previous reference to move1.
+---next------+
| v
move1 move2b move2a
^ | |
+---previous--+ |
^ |
+---previous-------------+
The system deallocates move1 and move2b.
move2a now has a previous reference to a deallocated GoMove object (move1).
+-- deallocated
v
move1 move2a
^ |
+---previous--+
The system finally deallocates move2a.
When dealloc of move2a accesses the previous reference the application crashes.
As in #369, the issue was found during unit testing, but it cannot be ruled out that this might also exist in production. And if not now, then in the future when some unrelated implementation detail changes.
The same timing problem that is exposed by issue #369 can cause a crash if the order in which GoMove objects are deallocated is changed.
Here is a similar schema as in #369, but with a different timing:
As in #369, the issue was found during unit testing, but it cannot be ruled out that this might also exist in production. And if not now, then in the future when some unrelated implementation detail changes.