I don't quite understand your argument, but just noticed my explanation was not sufficient.
What is happening is:
1. We enter ~UniqueModulePtr<MesaPlatform>
2. It destructs MesaPlatform
3. It unloads mesa.so
4. Somewhere near the end of ~UniqueModulePtr<MesaPlatform> ... crash! because that destructor was unmapped from memory but we are still trying to execute its instructions near the end of ~UniqueModulePtr<MesaPlatform>.
So UniqueModulePtr does crash once you fix all your leaks of mesa.so. The only way to avoid the crash is to hold an extra reference to the SharedLibrary, but that means UniqueModulePtr and make_module_ptr are pointless.
UniqueModulePtr seems like an elegant idea at first. But we all forgot that the template instance UniqueModulePtr<MesaPlatform> has its code inside mesa.so, while simultaneously needing to live longer than mesa.so is loaded. Once you fix your leaks, UniqueModulePtr will always crash.
I don't quite understand your argument, but just noticed my explanation was not sufficient.
What is happening is: r<MesaPlatform> r<MesaPlatform> ... crash! because that destructor was unmapped from memory but we are still trying to execute its instructions near the end of ~UniqueModulePt r<MesaPlatform> .
1. We enter ~UniqueModulePt
2. It destructs MesaPlatform
3. It unloads mesa.so
4. Somewhere near the end of ~UniqueModulePt
So UniqueModulePtr does crash once you fix all your leaks of mesa.so. The only way to avoid the crash is to hold an extra reference to the SharedLibrary, but that means UniqueModulePtr and make_module_ptr are pointless.
UniqueModulePtr seems like an elegant idea at first. But we all forgot that the template instance UniqueModulePtr <MesaPlatform> has its code inside mesa.so, while simultaneously needing to live longer than mesa.so is loaded. Once you fix your leaks, UniqueModulePtr will always crash.