Open psyklopz opened 5 years ago
Maybe MSVC chokes on the move semantics?
For what it's worth, this seems to be an issue with the underlying filesystem. I've not yet gotten a resolution for it. It seems to affect writing to eMMC-style memory, like an SD card.
CMake Build System, targeting C++ 17, MSVC 2017 Community, building a 32-bit DLL, running on Windows 10
I've observed this twice on production systems, and I know it sounds a little outlandish.
I have a multi-threaded application which has a Config class. This class reads the configuration file into member variables and then exposes those to the rest of the application with get/set-style accessors. It also provides a method to save the configuration file. All methods are accessed from different threads, so thread safety is a concern. Because of this, I wrap all of the set accessors and the Save() method with a std::lock_guard, using a shared std::mutex. The get accessors are not mutex-protected. (The read of the config is part of the constructor, and happens in single-threaded context.) I think this is sufficient thread-protection.
The system will sometimes (once every week) write out a config file of the expected length (4.7k, give or take). Except this config file is entirely NULL bytes (0x00). I can see this by viewing the file in a hex editor.
I don't quite understand how this could happen, because Configuru converts the object to a std::string before writing that to a file. If that string contained only nulls, I would expect to get a zero-length file, because it would stop at the first null-terminator. However, that does not appear to be the case. https://stackoverflow.com/questions/2845769/can-a-stdstring-contain-embedded-nulls
Any ideas? Have you heard of anything like this before?