QtCore4.dll_unloaded exception when usin external Wait function (LabVIEW)

[dadreamer]

I'm sorry for bumping such an old thread, but I'm facing similar issue.

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.

sick_icon_dll_crash.jpg

(Here's more detailed picture).

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 NI forums: https://forums.ni.com/t5/LabVIEW/QtC...t/td-p/3695012

[d_stranz]

This is almost certainly a LabView problem, not a Qt problem. Crashes on exit are often due to resources being released in the wrong order, object instances being double-deleted or inappropriately deleted, etc. and are a problem of the application. Correctly-written applications do not show such problems. It is possible that thread-related timing issues could also cause problems if threads are not shut down correctly before the app exits.

[dadreamer]

This is almost certainly a LabView problem, not a Qt problem.

Maybe you're right. But I don't use Qt in my program in any ways. The vendor-provided library does, so I could conclude that something's wrong with it. I tend to believe that this is threading issues, e.g. when the library is already unloaded but some thread is still alive and tries to reach some space inside that DLL. It might be confirmed indirectly by this issue - the users were having that QtCore4.dll_unloaded crash and the developer had to change the work with threads. That fixed the crash.

I could confirm or refute my guess by rewriting the same algorithm in another IDE (MSVC, Delphi etc). It would take some time but it would be clear, if it's related to LabVIEW or not.

[d_stranz]

But I don't use Qt in my program in any ways.

I think the LabView GUI is Qt-based. However, if you say that when your developer modified the code, the crash went away, it sounds to me like the problem is the relationship between the developer's threading code and the LabView internals. Likely there was either a timing issue over resource cleanup or the threading code was causing memory corruption that was not revealed until the app went through its exit shutdown.

[dadreamer]

I think the LabView GUI is Qt-based.

I used to think the same way, but the experts on NI forums told me that Qt is used only in a few toolkits, which I don't use currently. The rest of LV graphics is written in the core without external components.

if you say that when your developer modified the code, the crash went away

Well, it was just an example of similar issue and there it was really linked to the threading issues. So my issue also might deal with it or not. But I checked out all the toolkit code and every block seems to be correct and properly configured. I have also compared the code with C examples from SICK and it matches. That's why I don't think that my code or toolkit code is the reason, but it's likely a bug in SICK's C wrapper.

Meanwhile I have found a workaround to the problem. I placed LoadLibrary( /* path to ICON library here */ ) call right before the camera(s) init. 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.

Thanks for the help.