PDA

View Full Version : QtCore4.dll_unloaded exception when usin external Wait function (LabVIEW)



jellevlassenbroeck
9th April 2014, 16:27
We use LabVIEW for our software, where we call C++ DLLs containing QtCore classes to do most of the operations. Since a long time, we were confronted with a mysterious bug. Upon closing LabVIEW, we always got an exception with the following details:

Faulting application name: LabVIEW.exe, version: 12.0.1.4005, time stamp: 0x50d25315
Faulting module name: QtCore4.dll_unloaded, version: 0.0.0.0, time stamp: 0x520367f0
Exception code: 0xc0000005
Fault offset: 0x000000001864846e
Faulting process id: 0xec4
Faulting application start time: 0x01cf53fb199ed2db
Faulting application path: C:\Program Files\National Instruments\LabVIEW 2012\LabVIEW.exe
Faulting module path: QtCore4.dll
Report Id: 79aaef7e-bfee-11e3-9456-06e9c199960a
Faulting package full name:
Faulting package-relative application ID:

I couldn't grasp what was happening, especially since the exception kept on occurring after stripping both the C++ and the LabVIEW code almost to the bone. In the end, I found the cause but I can not find a complete explanation.

The exception occurs because we call a function from our DLL inside a loop in LabVIEW, which includes a Wait function of 1 ms. This LabVIEW Wait as introduced to make the UI more responsive, certainly not the ideal solution. Removing this Wait function removes the exception. Some more research on line shows me that the wait is handled by the OS, and the current thread is put to sleep for a period equal to the Wait input:

http://www.grahamwideman.com/gw/tech/dataacq/labview/labviewtimingmech.htm

Can anyone help me to understand what happens with the code in the DLL then? I stripped everything down to such an extent that there were only some QString objects still used in the DLL. Can the memory management of these objects be affected by putting the thread to sleep?

Any feedback is welcome!

dadreamer
27th September 2017, 11:17
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.

12598

(Here's more detailed picture (https://imgur.com/a/1EaEC)).

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/QtCore4-dll-unloaded-crash-when-using-SICK-3D-Camera-Toolkit/td-p/3695012

d_stranz
29th September 2017, 00:56
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
30th September 2017, 15:05
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 (https://forums.unknownworlds.com/discussion/comment/1906407/#Comment_1906407) - 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
30th September 2017, 18:11
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
4th October 2017, 13:32
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. :)