From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
LabVIEW 2014/2015 crashing with my wrapper library
Solved!
There has been a change in the Call Library Node around LabVIEW 2010 that could be part of the cause of your trouble.
Before that eventhough you defined cdecl calling convention, LabVIEW was attempting to second guess that selection based on the name decoration as it was exported from the DLL. Usually, stdcall functions have an appendix @<some integer number> where the integer number is in fact the number of bytes the function expects on the stack as parameters. This appendix is however not shown in the function selection list box inside the Call Library Node as LabVIEW also tries to prettify the function names for the selection list box. This appendix is also not required even if the function is exported as stdcall and the developer has any possibility of suppressing that appendix despite using stdcall or causing something that looks like this appendix to be added to a function name, despite of exporting the function as cdecl.
Starting with LabVIEW 2010 or 2011 this second guessing has been removed as it could prevent someone from calling a function that happened to have something looking like this name decoration but having been explicitedly exported as cdecl anyhow. The totally proper way would have been to also add some mutating code that when upgrading VIs from earlier versions than this with these characteristics would explicitedly modify the calling convention but that was left away for some reasons.
So check if your Call Library Nodes define cdecl and if they do, try to find out if the DLLs actually are exported as such or not.
Of course there are other possibilities for crashes and errors when using Call Library Nodes. There is nothing that LabVIEW can use to make sure that everthing goes right when calling external functions. A wrongly configured parameter datatype can cause a crash, an error 1097, an unexplainable runtime corruption of data in your diagram or of the VI itself, or seemingly nothing at all. Same about if your function expects an array or string pointer to write into and you don't allocated it in the LabVIEW diagram or not as large as the function expects. All these errors will cause some memory corruption somewhere during the call of the DLL function but this corruption may not cause an immediate error. It could cause seemingly unrelated operations in LabVIEW to fail or in the worst case not cause any failure at all until you recompile the VI, start it up in a different way or in a different application, etc, etc. Also a new LabVIEW version always has the chance of surfacing more such errors since the memory layout changes in every version due to changes in the compiler, heap allocator and many other things, so that memory that got previously corrupted but didn't cause any noticable effect suddenly is located in a place that hosts vital data pointers.
Hi rolfk,
I really appreicate your response.
I have checked the C DLL functions are exported with _decl which maps to __stdcall. All the VI library nodes are configured to use stdcall. The VIs work as expected using LV2010 all of the parameters are simple native data type mostly numerics.
After going through more crash logs it seemed to indicate an error with the C DLL. I turned on Maximum error checking for all my Call Library Nodes. During execution LabVIEW stopped on one of the VIs and received a dialogue with the follow error. For the time being I have disabled the call to "Get_Model_Name". LabVIEW hasnt crashed since I have disabled the call.
Internal to the library I'm doing a strcpy which looks normal. So I beginng to believe the problem is with the configuration of the Call Library Node.
And how do you allocate the String that you pass to the second parameter? Just wiring an empty string constant to it? While in LabVIEW code you don't have to worry about allocating memory prior to calling some other VI, that is definitely not true when calling C functions. That function wants to write some information into that string and for that to work the caller (You on the LabVIEW diagram) has to allocate enough memory space for that.
You have to find out from the documentation of that API what the maximum buffer size is and allocate that much of string size. There are two ways to do that
1) Use an Intialize Array with an U8 as input type and the right amount for the buffer size and converte it with a Byte Array to String node.
2) Do you see the Minimum Size in the configuration dialog? Enter there the number of bytes the string needs to minimally have according to the documentation.
To answer the inevitable question right away. Yes it didn't crash in LabVIEW 2010 but did corrupt memory anyways somehow even there. Not every memory corruption immediately results in a crash. There are many possible outcomes from such corruptions and they can change depending on the computer you run your application, the amount of memory available, the moon phase and how your emotional state is at the moment (the last two aren't very serious but also not entirely unrtrue). The memory layout at the moment when running your function can very much influence what will happen from such corruptions. It can produce strange unexplainable results in your program when actual data values that are storing values in wires are overwritten, or your VIs can get corrupted and if you save them to disk afterwards get unreadable, or the computer produces an error dialog much later when you try to shutdown LabVIEW and your app, or there seemingly happens nothing (but the corruption still occures, it just didn't corrupt vital data in memory).
With the change to LabVIEW 2014 the memory layout changed somehow, maybe due to tighter optimizations in this new version and suddenly your DLL does overwrite memory that is very vital for the operation of your app in LabVIEW.
