When we quit, objects with static storage are destroyed. Since the order is undefined, we basically cannot reference other objects in destructors, unless we own them or they are reference counted.
One case that seems to be an actual problem is the oak::process_t type — based on crash logs this often seems to be destroyed last, and it unregisters itself in its destructor, but using an object that it previously did not own (but obtained via a sort of factory function).
This is a fairly subtle bug: We were implicitly creating a temporary std::string object and requesting c_str from this object.
This C string’s lifetime was that of the temporary std::string, and as we did a lot of std::string creation in the following line, with the new libc++, there was a good chance that the temporary string buffer would be re-used and so, our working directory would be set to a bogus value.
This closes issue #329.
I was initially under the impression that no data should be sent past EOF but from testing it is clear that this assumption is incorrect. It’s unimportant though as we do handle the case (though we didn’t initially, and that’s why I put in the fprintf, to verify the situation I guarded for actually was happening).
Previously this was under the OakSystem framework which depends on the io framework meaning that the io framework itself was unable to obtain a basic environment, which is necessary for next commit.
