Open rosenrodt opened 5 years ago
I think I know what the problem is. And it is not related to Boost.Compute
If you have a wrapper similar to compute::context
and let the wrapper's call clReleaseContext
upon destruction, define that wrapper in global scope or static and you can repro this issue.
Mine is something like this
struct context_wrapper
{
cl_context m_context;
context_wrapper() : m_context(0)
~context_wrapper() { if (m_context) clReleaseContext(m_context); }
void attach_context(cl_context context) { m_context = context; }
};
context_wrapper gContext;
void DLL_EXPORT func()
{
cl_context context;
// initialize cl_context
// --------------------
// ...
// --------------------
gContext.attach_context(context);
}
Call this imported DLL function and it gives you the segfault and also similar stack trace. I am still not certain why it refuses to exit program nice and clean, and how Boost.Compute can workaround this problem (if it is indeed confirmed by more people)
EDIT: I should've made it clearer; calling the imported function does not give you segfault right away, but instead at program exit
Thanks for the info. I'm not sure when I'll be able to look at it and debug it. Maybe in the weekend.
Are you sure that myexe
has access to OpenCL dynamic library?
target_link_libraries(mylib PRIVATE
BoostCompute::BoostCompute
)
Doesn't that commnad mean that BoostCompute::BoostCompute
will not propagate to OpenCL::OpenCL
to myexe
?
Doesn't that commnad mean that BoostCompute::BoostCompute will not propagate to OpenCL::OpenCL to myexe?
It is intended that myexe
has zero knowledge about OpenCL and Boost.Compute used by mylib
Some updates:
My current approach for the driver bug is to call clRetainContext()
, clRetainDevice()
, and clRetainCommandQueue()
for all compute::default_xxx()
's somewhere in the dynamic library. With that the segfault seems to go away.
@jszuppe if you could independently verify this, how can we approach this issue for Boost.Compute, assuming the driver do not get the timely fix?
Maybe we need to provide optionally something like compute::system::release()
to release every statically-declared OpenCL resource from the OpenCL runtime. My latest finding is that it will also require clearing the global program cache in order to avoid the segfault.
There seems to be an issue with current Nvidia and Intel platform (AMD does not seem to have this issue) when I compile Boost.Compute in a dynamic library; segfault is reported during some OpenCL resource cleanup while exiting. The interesting thing is if I statically link the same library this becomes a non-issue. Update: On MacOS it doesn't seem to have this issue
I am able to reproduce this issue with a few lines of code (here). The site raising the exception might be a bit different (at
program::~program()
orcommand_queue::~command_queue()
orcontext::~context()
) if I added or removed a few boost::compute APIs here and there.Any thoughts on why this happens? I am hesitant to call this a Boost.Compute bug, but I have tried myself and I can't reproduce the problem in plain OpenCL API.
A few notes:
36c89134
Full stack trace 1 (Nvidia platform)
Full stack trace 2 (Nvidia platform)
Full stack trace 3 (Intel platform)