Unknown error "driver shutting down" raised when exiting application

[ColinChargyBentley]

Hi, When my software uses OIDN, upon exiting, an unknown error is raised with error message "driver shutting down" during the call to oidnReleaseDevice. Why is that ? Regards, Colin Chargy

[atafra]

Hi Colin,

What I can say for sure is that this error does not originate inside OIDN, it just passes it along (that's why it's an unknown error). More information is necessary to be able to investigate this further: what kind of device are you releasing (CPU, GPU, which type?), the OS, the system configuration (CPU, GPUs, etc.), driver versions, etc.

Also, what is the frequency of this error? Does it happen every time or only occasionally? Does it happen only on this machine or other similar machines too?

Regards, Attila

[ColinChargyBentley]

Hi Attila, I'm running OIDN under CUDA on a NVIDIA GeForce RTX 2070 (driver version 31.0.15.3734). The CPU is Intel(R) Core(TM) i9-9920X with 32 of RAM installed. The OS is: Edition Windows 11 Enterprise Version 22H2 Installed on ‎6/‎30/‎2023 OS build 22621.2283 Experience Windows Feature Experience Pack 1000.22662.1000.0

Need anything else ? Regards, Colin

[atafra]

Thanks for the details. The error message seems to come from the CUDA runtime. An important detail is that the issue happens upon exiting. Are you calling oidnReleaseDevice when a static variable/object is being destroyed? If that's the case, I think I know what's the problem.

oidnReleaseDevice calls some CUDA runtime functions to clean up resources but it seems that by this time the CUDA runtime has been already unloaded. OIDN has no contA frustrating issue about shared libraries in general is that the unloading order is undefined, so if you're calling functions of some other library in a static variable's destructor, it's not guaranteed that the library will be still loaded at that time. There are basically two robust solutions to this problem:

• Avoid keeping OIDN resources in a global/static object. This would be the ideal solution but it's not always possible.
• Do not call oidnReleaseDevice at all. If this would be called only upon exiting, it's not really necessary because the resources would be released at process exit anyway, so no real leak would happen. This is probably the easiest solution.

There might a third option too: with some tricks/hacks it may be possible to change the library unloading order for your application but it would still rely on undefined behavior, and correctness wouldn't be guaranteed.

[ColinChargyBentley]

Hi Attila, I will delete the DeviceRef before closing the app. Could you add a release method to oidn::DeviceRef to avoid using dirty tricks to release them when needed (such as device.~DeviceRef() or oidn::DeviceRef deviceCopy = device; UNUSED(deviceCopy); or the need to store a DeviceRef in another smart pointer. Thanks for the explanation. Regards, Colin

[atafra]

Maybe I misunderstood something but it seems you need both a release() and a retain() in DeviceRef, right?

release() would be roughly equivalent to device.~DeviceRef(), but you can already release it in cleaner and safer way by simply device = nullptr.

Is the intent of oidn::DeviceRef deviceCopy = device; UNUSED(deviceCopy); to call oidnRetainDevice(), to prevent the device to be released?

[ColinChargyBentley]

This is a mistake, the correct code (other than device = nullptr;) would be oidn::DeviceRef deviceCopy = std::move(device); UNUSED(deviceCopy);. Thanks

[atafra]

I could still add release() as an alternative to device = nullptr because standard smart pointers also have this functionality. But you don't need anything else, right?

[ColinChargyBentley]

I'm all right, I wasn't aware of the = nullptr trick.