Problem with clRelease functions

Problem with clRelease functions


I have an issue with clRelease functions (clReleaseContext, ...). I developped a C++ library to manage easily OpenCL functions and a test application to control its working.

This application works fine and all clRelease functions are call with success.

Then I developped an other library that uses the first lib to use OpenCL and a test application to control its working.

This application stops when I try to enter in the first clRelease functions namely clReleaseContext.

The same problem appears with Intel and NVidia OpenCL driver. So this is not a driver problem but a usage problem.

To summarize:

OpenCL -> LIB_A -> TEST_APP_A : OK

OpenCL -> LIB_A -> LIB_B -> TEST_APP_B : not OK

Is someone could help me to find the problem?


4 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

I found a solution but I still don't understand the problem.

Here is the architecture:

class A is a singleton and creates the context.
class B is a singleton and have the member static A* instance.

If I remove the static member of A* in class B and I give the instantiation of A to other functions calls to clRelease functions work fine.

So this is the only way to avoid the issue, but I don't understand why I can't have a static instantiation of a singleton in a class.


I don't know how did you implement your singletons but assuming the implementation using static objects:

1. C++ defines static objects constructors and destructors execution order only for the objects that instatiated in the same CPP file. Relative order of executon of contructors and destructors between different CPP files is not defined.
2. On Linux relative execution order between DLL constructors/destructors (process attach/detach on Windows) and static objects contructors/destructors is also not defined.
3. On Linux relative order of different shared objects (DLL) contructors/destructors not defined. On Windows the same picture for dynamically loaded DLLs (and OpenCL drivers are dynamically loaded)

As a result it is not a good C++ practice to create static objects that either:
1. depend on each another (as in your example)
2. depend on other DLLs (as in your example they depend on OpenCL drivers)

As far as I know in most cases this problem is solved by using static pointers instead of static objects and never deleting this objects after initial allocation or by using some "shutdown" function that must be called from the process "main" function or one of it descendants.

Ok thank you for the explanation!

Leave a Comment

Please sign in to add a comment. Not a member? Join today