Intermittent crashes caused by DLL unload issues in ocl module (Bug #3450)
| Status: | Open | Start date: | 2013-12-20 |
|---|---|---|---|
| Priority: | High | Due date: | |
| Assignee: |  Andrey Pavlenko |
% Done: | 0% |
| Category: | ocl | ||
| Target version: | - | ||
| Affected version: | branch '2.4' (2.4-dev) | Operating System: | Windows |
| Difficulty: | HW Platform: | x86 | |
| Pull request: |
Description
Myself and a few others have been seeing intermittent crashes when the ocl module performance tests shut down. These crashes sometimes look like segfaults and sometimes look like pure-virtual function calls. I think I have narrowed it down to a problem in the order that DLLs unload.
It looks like the OpenCL runtime DLL is being unloaded before the OpenCV DLL (opencv_ocl247d.dll, in this case) is being unloaded. And when the OpenCV DLL tries to clean up its OpenCL resources in its DllMain, the memory backing these resources has already been de-allocated. Both DLLs are being unloaded by Windows inside of exit().
Normally, I would expect the unload order to follow DLL dependency rules. But the OpenCL DLL is loaded at runtime using LoadLibrary. And unfortunately, it looks like this doesn't affect Windows’s view of DLL dependencies. This is counter-intuitive, but covered here:
http://blogs.msdn.com/b/oldnewthing/archive/2005/05/23/421024.aspx
I don’t have an easy fix for this. It seems like the OpenCV library should not be touching OpenCL entry points in OpenCV’s DllMain (on detach). But it seems like it would be hard to know where to release the context. Perhaps when the last oclMat is destroyed? But this might cause lots of unnecessary startups and shutdowns when applications iterate in a loop that starts and ends with no oclMat instances.
This problem might be related to this one as well, but I can't be sure: http://code.opencv.org/issues/3355.
Related issues
| related to Bug #3355: Pure virtual method called | Done | 2013-11-01 |
Associated revisions
Resolves bug #3450 (Improperly cleaning up resources in DllMain)
History
Updated by Ilya Lavrenov about 11 years ago
- Category set to ocl
Updated by Anna Kogan about 11 years ago
- Affected version changed from 2.4.7 (latest release) to branch '2.4' (2.4-dev)
- Assignee set to Andrey Pavlenko
- Status changed from New to Open
Updated by Alexander Karsakov about 11 years ago
Hi Aaron.
We fixed this problem by pull request (https://github.com/Itseez/opencv/pull/2448). Could you please check that issue is solved for you?
Description of the cause of problem on MSDN(http://msdn.microsoft.com/en-us/library/windows/desktop/ms682583(v=vs.85).aspx):
When handling DLL_PROCESS_DETACH, a DLL should free resources such as heap memory only if the DLL is being unloaded dynamically (the lpReserved parameter is NULL). If the process is terminating (the lpvReserved parameter is non-NULL), all threads in the process except the current thread either have exited already or have been explicitly terminated by a call to the ExitProcess function, which might leave some process resources such as heaps in an inconsistent state. In this case, it is not safe for the DLL to clean up the resources. Instead, the DLL should allow the operating system to reclaim the memory.
Updated by Maksim Shabunin over 9 years ago
Issue has been transferred to GitHub: https://github.com/Itseez/opencv/issues/4664