Consider the following:
// Assume this is compiled to "SomeLibrary.so"
// And this is an application that loads "SomeLibrary.so"
template<typename RET, typename... ARGS>
typename std::function<RET(ARGS...)> loadSymbol(void* handle, const std::string& symbol)
typedef RET (*Signature)(ARGS...);
// This smells funny...in a bad way...
return std::function<RET(ARGS...)>((reinterpret_cast<Signature>(dlsym(handle, name.c_str()))));
void* handle = dlopen("SomeLibrary.so", RTLD_LAZY);
loadSymbol<std::vector<int>&&>(handle, "action"); // <-- Boom
This crashes on the linux distribution that I'm working with. Is there something obvious that I'm doing wrong or is something more "linuxy" happening?
Last edited on
It's possible that the shared lib and the app have different heaps, happens all the time with Windows DLLs.
The memory is allocated in the shared lib's heap and that heap address is released to the application's heap.
I think it is more of a stack problem. Dynamic memory (vector<T>*) works just fine but I would like to avoid pointers if at all possible...
Thanks for the info norm. That was a simple mistake on my part while creating a small scale example of the condition.
The code indeed fails on Linux Mint under clang 3.4. Perhaps I'll see if an update is available for clang.