Memory leaks in libOpenCL.so.1!khrIcdVendorAdd

[MichaelTutin]

Intel Inspector detects memory leaks for two allocations in khrIcdVendorAdd():

1. Error: Memory leak: 16 Bytes:

libOpenCL.so.1!khrIcdVendorAdd - /OpenCL-ICD-Loader/loader/icd.c:135
libOpenCL.so.1!khrIcdOsVendorsEnumerate - /OpenCL-ICD-Loader/loader/linux/icd_linux.c:125

2. Error: Memory leak: 80 Bytes

libOpenCL.so.1!khrIcdVendorAdd - /OpenCL-ICD-Loader/loader/icd.c:153
libOpenCL.so.1!khrIcdOsVendorsEnumerate - /OpenCL-ICD-Loader/loader/linux/icd_linux.c:125

Looking at the code in icd.c is seems that vendor structure is initialized and added into khrIcdVendors global list, but there is no explicit deinitialization function that would free those elements. Probably one of the options to fix that issue would be to add a function with _attribute_((destructor)) on Linux or DllMain() handler on Windows to handle library unload event and deallocate those blocks.

[Kerilk]

Thanks for reporting the issue.
The termination of the loader is an open problem. I'll try to summarize the issues here:

• We leak memory,
• Libraries are not unloaded (drivers, layers),
• We don't have a termination API for layers (so they must use at_exit() for termination).

Adding termination to the loader nonetheless may present a risk that user application (less likely) or libraries (more likely) would break, especially those that rely on at_exit or similar callbacks (C++ static destructors?) that call OpenCL APIs (usually to release OpenCL resources), and that would be called after the loader is de-initialized.

I think this topic needs to be addressed, but needs careful discussion/consideration. It should be noted that race conditions in shared libraries loading/unloading is not a subject I am particularly confident discussing, so everything I say here should be taken with a grain of salt.

note: ocl-icd is behaving similarly.

note: the layer infrastructure may be able to help here: we could add a no-op stub/layer once we enter de-initialization (and either always return SUCCESS or a dedicated error code?). This should prevent segfaults inside the loader. I think CUDA has a similar mechanism.

[Yanfeng-Mi]

Any updates on this issue?

[wenjiew]

Is there any update on fixing this issue? Thanks!

[Rikyu1]

How can we fix this issue?

[JablonskiMateusz]

Created PR with fix: #217

[bashbaug]

One item we briefly discussed in last week's teleconference: We recently added the ability to have "loader extensions" (see the ICD loader info PR #188). Could we add a similar "loader extension" that allows an application to safely and explicitly de-initialize the ICD loader on the application's schedule, rather than de-initializing the ICD loader implicitly when the ICD loader is unloaded?

This isn't a perfect solution because it requires an explicit call to "clean up", but it avoids some of the unloading race condition concerns described above.