Details
-
Sub-task
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
-
None
-
None
Description
ScopedResolver holds a shared_ptr to a std::promise to do async stuff while the calling thread blocks. The spec allows promise::set_value to unblock future::wait immediately which causes future::get_value to race to read whatever the promise contains before the state and value owned by the promise is destroyed. In this case even though the ScopedResolver holds a shared_ptr to the promise which looks like it'd prevent this but it's possible for wait to unblock fast enough for the destructor on ScopedResolver to be called which ends up destroying the promise. GCC's implementation of promises and futures will hit this and will show up in valgrind as a bunch of invalid reads if the timings are right to set up the race.
Simple fix right now is make sure the callback captures a shared_ptr to the promise. Longer term fix may be to make a class that encapsulates the promise and future with a reference counting mechanism to prevent more of these bugs and use that instead of the std lib versions.