LabVIEW
LabVIEW crashes while developing code
Solved!
@JoeLV1992 wrote:
We do have a dll from a third party vendor for the card we use. The two development PCs we have that are crashing don't have the card in them. I will have to check with my co-worker to see if he has experienced the "crashing" on the PCs with the card in them. No we don't have any raspberry Pi in our development. I will also see if there is a 32-bit vs 64-bit compilation of the dll issue here as well. My PC has Win7/64 bit. Curious to see what my co-workers PC has as well.
It could be the DLL and it could happen only if connected or only if not connected. Note that dlls can execute code when loaded, or when a new thread calls it. So crashing LabVIEW while not having run the dll doesn't mean it's not the dll.
If you have 64 bit LabVIEW, the 32 bit dll won't run. If you have 32 bit LabVIEW, a 64 bit dll won't run. If you're code isn't broken, you have the right dll.
There could of course be a problem in the specific (32 or 64 bit) dll you're using, that isn't in the other one.
I haven't heard about 32 bit dll problems on 32 bit windows, but on driver level, there could be something wrong of course.
Search LabVIEW like a graph! 
Some files get merged by SCC systems. you might look into that.
There's a list of things that shouldn't be merged (all files related to LV), but I'll have to dig. A lvproj file might get merged, as it's recognized as XML.
@JoeLV1992 wrote:
Update. My coworker and I use SVN/Tortoise SVN as our repo. We unlocked the entire repo as part of our cleanup efforts. Doing this seems to alleviate the crashing. There are moments where LabVIEW would not responds, but if we waited a few minutes, it would return. We also did a project mass compile to ensure all the files are linked and compiled for our latest version.
So I don't know if this is the issue, but if for some reason LabVIEW needs to touch every file in the project and it cannot because it is marked read only. Has there been any posts about SVN locked files causing this issue?
LabVIEW is constantly recompiling itself every time you make a change. Update a typedef, and everything that uses it gets compiled. To alleviate a lot of this, you can set the environment to separate compiled code from source code so that only the things that need compiling get compiled - indeed, this change was incorporated to help versioning software like SVN from having to mark everything as changed all the time - but you still get things that are recompiled. I suppose LabVIEW wouldn't take kindly to not being able to write to a file it had just recompiled.
I admit that I've never tried to develop code in a read-only folder, but I wouldn't want to, either.
@JoeLV1992 wrote:
Update. My coworker and I use SVN/Tortoise SVN as our repo. We unlocked the entire repo as part of our cleanup efforts. Doing this seems to alleviate the crashing. There are moments where LabVIEW would not responds, but if we waited a few minutes, it would return. We also did a project mass compile to ensure all the files are linked and compiled for our latest version.
So I don't know if this is the issue, but if for some reason LabVIEW needs to touch every file in the project and it cannot because it is marked read only. Has there been any posts about SVN locked files causing this issue?
I have been in several projects with multiple developers, using read-only / locked files in SVN and never had an issue with it. I have had a few occurences with SVN messing with the lvproj or class-file. The file can become corrupt but still seem to work, until LV crashes (as far as I can recall, and that might have been an issue on older LV-versions only).
If everything seems to work for a while now, maybe you could try locking the files again to see if it starts crashing again. It could be the mass-compile that fixed it.
The access violation is so common in the LabVIEW reports because it is a generic error. It simply means that something somewhere inside the process tried to access a memory address that is not valid. This can be caused by bugs in LabVIEW (very seldom nowadays but not entirely impossible), badly configured Call Library Nodes, or bugs in external shared libraries.
Your little tidbit about changing the library path from being defined in the Call Library Node to passing it as parameter from the diagram solving your crashing problem considerably points VERY STRONGLY at the last possibility. If you specify the library path in the Call Library Node, the DLL is loaded at the time the VI is loaded into memory. When loading a DLL, Windows will also call its DLLMain routine which by default does nothing, but it can very well do whatever the DLL developer wishes to do, including loading other DLLs, system drivers, allocating memory, start up internal threads, etc. etc. With the library name specified from the diagram, the DLL will only get loaded the first time you execute that VI. So that is the whole difference and your DLL definitely seems to do something that is not entirely kosher, when it is loaded into memory. It could be that it starts up some thread or whatever that tries to access the hardware drivers and after some time somehow stumbles over its own feet when that hardware is not physically present. Or it is effectively corrupting memory somewhere that crashes as soon as that memory area gets accessed for something else. Memory corruptions are very tricky since if your DLL overwrites some memory that it has no business of accessing, this could be a data structure used in LabVIEW somewhere and as soon as LabVIEW needs to access that memory it wanders of into nirvana as the infomation in there is not correct anymore. However it's not so likely that the problem is happening in LabVIEW code itself because you would usually get some specific stack trace information in the crash logs if that was the case. So to me it looks like the DLL driver does something when it gets loaded that will likely crash after some time, maybe only when the hardware isn't physically present.
Basically whenever you access any DLLs in your LabVIEW project through the Call Library Node, chances for a crash error to be in LabVIEW itself compared to related to the DLL (either configuration errors in the Call Librrary Node or bugs in the DLLs) is something like 1 to 100, so concentrating your efforts in looking into LabVIEW errors rather than to the use of that DLL is really not an effective way to spend your time. And yes the fact that you can run your software even several times without a crash, says absolutely nothing about the correctness of Call Library Node configurations or the bug status of any DLL you incorporate into your application. Many errors don't crash immediately and sometimes never, until you make some seemingly unrelated changes to your program in a completely different part of it and suddenly it starts to crash at random moments.
