Fix crashes in Windows if mixing Debug/Release with interprocess synchronization primitives #251
Conversation
This file contains 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
…a fixed binary format The windows_bootstamp clasa uses a simple C style string so that the binary format is the same in debug and release builds There can be multiple modules which use boost interprocess named objects (e.g. named_recursive_mutex). These modules can be built in release or debug mode and hence the binary format of std::basic_string<> will differ. This results in an access violation if the windows_intermodule_singleton for the windows_bootstamp<CharT> is created in a module built in release mode, and accessed in a module build in debug mode (or vice-versa). It is not only release versus debug that is an issue. The access violation could also occur if the modules are built with different compilers. The solution is to create a new windows_intermodule_singleton because we cannot change the format of the existing windows_bootstamp<CharT> class. The new singleton uses only C functions to allocate and free the the character string. This ensures that the build configuration mode or the compiler do not affect the binary layout of the singleton object. The new windows_intermodule_singleton has a class name which includes a version number. E.g. windows_bootstamp::version1 If the layout of this class needs to change, then the version number must be incremented. This would then create a new singleton, which is required.
MikWells
changed the title
MikWells
changed the title
MikWells
changed the title
MikWells
changed the title
MikWells
changed the title
MikWells
changed the title
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.
…a fixed binary format
The windows_bootstamp clasa uses a simple C style string so that the binary format is the same in debug and release builds
There can be multiple modules which use boost interprocess named objects (e.g. named_recursive_mutex). These modules can be built in release or debug mode and hence the binary format of std::basic_string<> will differ. This results in an access violation if the windows_intermodule_singleton for the windows_bootstamp is created in a module built in release mode, and accessed in a module build in debug mode (or vice-versa). It is not only release versus debug that is an issue. The access violation could also occur if the modules are built with different compilers.
The solution is to create a new windows_intermodule_singleton because we cannot change the format of the existing windows_bootstamp class. The new singleton uses only C functions to allocate and free the the character string. This ensures that the build configuration mode or the compiler do not affect the binary layout of the singleton object.
The new windows_intermodule_singleton has a class name which includes a version number. E.g. windows_bootstamp::version1
If the layout of this class needs to change, then the version number must be incremented. This would then create a new singleton, which is required.
This is likely to resolve #94