Check serialized coroutine state is valid #101
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Check the build ID matches when deserializing objects
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When serializing a durable coroutine, the serialized representation is probably only valid for the build that generated it.
There are no checks to ensure that the serialized representation of a coroutine is valid for a particular build. When the serialized representation is no longer valid, the program crashes with cryptic error messages.
This PR fixes the issue by prefixing the serialized representation with a build hash. If there's a hash mismatch,
Unmarshalreturns anErrInvalidStateerror that the program can handle gracefully. For example, the program may choose to restart the coroutine.Rather than hashing the binary (which might be large), we extract the Go Build ID and use it as the hash. The build ID changes when the source changes, but also when the compiler and any other dependencies change too (which both may affect the serialized representation of coroutines). I adapted the ELF and Mach-O parsers from https://github.com/golang/go/tree/3803c8588/src/cmd/internal/buildid, but kept it simple and only added a parser for binaries generated by the Go compiler (and not gccgo).