QtCore4.dll_unloaded crash when using SICK 3D Camera Toolkit

[dadreamer]

I work with Ranger E50414 3D Cameras by SICK IVP in LabVIEW and use the vendor-provided toolkit for that. So, from time to time my program, which works with the cameras, crashes on exit with the exception C0000005 (Access violation) for QtCore4.dll_unloaded module. It's somehow related to QtCore4.dll, which, as I know, is used internally in vendor's library icon_c_51.dll. Here's the screenshot of the crash along with the threads' information about which threads are still alive when the program is crashed.

I should notice that such event happens only when I close already stopped VI and then close LabVIEW or when I close compiled app (exe) completely. So, this happens in both LabVIEW and exe variant. And this happens not every time, but sometimes (especially, when I quickly close my app or when it closes itself by some conditions). I suppose, it's related to thread synchronization in icon_c_51.dll or Qt DLLs, but my skills aren't enough to figure it out.

I'm working in LabVIEW 2016 32-bit on Windows 7 x64 and using the toolkit sick_lib_sick_3d_camera_toolkit_for_labview-3.1.1.38.vip. Here are the versions of the DLLs:
icon_c_51.dll : 5.1.2.49
QtCore4.dll : 4.5.0.0
QtGui4.dll : 4.5.0.0
QtXml4.dll : 4.5.0.0
Tried to switch to 4.7.4.0 Qt lib's but it didn't help. Also tried to use an explicit loading / unloading with LoadLibrary / FreeLibrary to no avail.

I'm familiar with C, asm and debuggers like IDA and ollydbg but I'm not a Qt programmer so don't know which routines I should check. Any ideas are welcome.

Cross-post on Qt forums: http://www.qtcentre.org/threads/58740-QtCore4-dll_unloaded-exception-when-usin-external-Wait-functio...

[rolfk]

Crash on exit of LabVIEW (or anytime between calling a Call Library Node and exiting, but not at the moment you call a Call Library Node) can and almost always is still related to memory corruption happening during Call Library Node execution.

It can be because of a badly configured Call Library Node where the types don't match, because a VI passes in a to small buffer to the Call Library Node where the external function wants to write into that buffer, or simply a real bug in the external function too.

It could theoretically also be related to some conflict between something the QT Toolkit does and LabVIEW (some other components might use a different version of that Toolkit) but the chance for that is pretty low in comparison to the above mentioned problems.

This would mean that the original Toolkit developer has probably some debugging work to do!

[dadreamer]

Thank you, rolfk! I'm now double-checking all the functions wrapped into VIs and their prototypes according to the manuals from SICK.

By the way, I saw that LabVIEW also uses Qt libraries for graphics. I wonder if it properly handles the cases when its own and custom Qt libraries are used simultaneously.

[rolfk]

AFAIK, LabVIEW itself doesn't use QT, I believe there are Toolkits like the Data Logging and Supervisory Toolkit which have components that link to QT but core LabVIEW does not use QT at all. What LabVIEW does use is OpenGL for the modern controls and the 3D Picture Control but that is independent of QT, although they might possibly interfere with each other if run on buggy graphic card drivers.

[dadreamer]

Well, I checked out all CLFNs and altered some parameters. In particular, I switched all the handles, which internally appear to be the pointers, from I32 to signed pointer-sized integers. That allowed me to run the app in 64-bit LabVIEW. The whole program works just fine but still I see that annoying crash on exit:

It's interesting that the vendor made tool Ranger Studio never crashes. But it doesn't use this C wrapper DLL. It works with underlying C++ DLL instead. Maybe, something's wrong with the wrapper. To figure it out I need to rewrite my app in C-like IDE and hope that I'll see the crash there.

[rolfk]

---

@dadreamer wrote:

It's interesting that the vendor made tool Ranger Studio never crashes. But it doesn't use this C wrapper DLL. It works with underlying C++ DLL instead. Maybe, something's wrong with the wrapper. To figure it out I need to rewrite my app in C-like IDE and hope that I'll see the crash there.

---

This is certainly an interesting candidate. In addition make sure that any buffer passed to the DLL, which the function is supposed to fill in, is actually sized to the needs for that function. DLLs don't work like LabVIEW where you don't worry about allocating a memory buffer for a string (or array) you want to generate. If the function expects an array of 1024 double floating point values to write some data into, then you should really make sure that you actually pass in an array to the Call Library Node that is presized to at least 1024 elements. The DLL has no way of resizing that array for you and LabVIEW has no way of knowing that the DLL wants an array of 1024 (or 1 million or 10) elements. 

[dadreamer · Accepted solution]

Almost intuitively I have found a workaround to the problem. I placed CLFN block right before the camera(s) init with LoadLibrary("icon_c_51_x64.dll") call. In the end of the code I'm not doing FreeLibrary. That makes LabVIEW to retain the DLL (and QT lib's tied to it) from unloading on VI's close so it unloads only on process (exe) exit. No crash yet.

There is another workaround but it's kinda "nasty" - call ExitProcess(0) at the end, so all the threads receive their signals and finish normally. But it doesn't allow LabVIEW to do clean up work and is suitable only in exe variant (because I don't want to see LabVIEW closing when my program is stopped).

I'm not going to dig deeper because it takes a lot of free time and the things become more and more complex. On good terms the ICON C wrapper should be carefully debugged and rewritten if it's needed.

---

@rolfk wrote:

In addition make sure that any buffer passed to the DLL, which the function is supposed to fill in, is actually sized to the needs for that function.

---

I checked all the CLFNs in the toolkit and they seem to be correct. The DLL returns strings only in several calls, but it doesn't require some external buffer. It allocates the buffer internally and outputs the pointer to it. I have compared LV code to the C examples and it matches them. Not having sources for C wrapper I have to finish on this.