LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

selecting front panel properties after runing causes crash

After I run my program (which uses several call library function nodes to access numerous dll files) and then try to alter the properties of a front panel control labview crashes. Sometimes it simply locks up, other times it displays a recoverable error message, and finally sometimes it displays a hard error message from which I cannot recover and only send an "error report." While the errors are annoying I really want to know why changing the properties causes them which may lead me to other problems in my code. Thanks for any thoughts you can provide.
-Dave
0 Kudos
Message 1 of 6
(3,041 Views)
Does this happen without the Dll calls? If not, it could be something in the dll's corrupting memory due to bad memory allocation or calling conventions or other problem. If possible, can you post code that demonstrates the problem. Good luck.

Jeff P.
0 Kudos
Message 2 of 6
(3,041 Views)
Hi Dave,

How are you attempting to alter the properties of your front panel controls? Do you programmatically change them while it is running using property nodes, or do you physically change them in development mode after the application has finished running? This may provide some clues as to why you get crashes. In addition, the above suggestion about your DLL accesses are definitely another reason why these crashes may be occurring.

Jeremy L.
National Instruments
Jeremy L.
National Instruments
0 Kudos
Message 3 of 6
(3,041 Views)
Thanks for the reply Jeremy, I try to change them manually after the program stops. I use a property node to alter other controls but not the one I discovered the problem on. I am suspecting a memory leak within the dll or some problem with the way I am passing strings and arrays in and out of my call library function nodes. (I initialize the strings and arrays before the function is called, so I am leaning toward an issue in the C code.

Also another oddity, when I first open labview and run the code it works great, however if I try to close the VI but not labview then run it again it fails. I think that labview is not dropping the dll. Is there a way to force it to release the dll?

Thanks in advance for any help or suggestions you can offer.
0 Kudos
Message 4 of 6
(3,041 Views)
NIDave wrote:

> Thanks for the reply Jeremy, I try to change them manually after the
> program stops. I use a property node to alter other controls but not
> the one I discovered the problem on. I am suspecting a memory leak
> within the dll or some problem with the way I am passing strings and
> arrays in and out of my call library function nodes. (I initialize
> the strings and arrays before the function is called, so I am leaning
> toward an issue in the C code.

Well here you go. Calling a DLL and then getting (delayed) crashes in
LabVIEW absolutely always means that the DLL is trashing some memory it
shouldn't. This either happens by passing wrong data (DLL expects by
reference and you pass by value) or arrays and string not initialized or
not intialized to be large enough. Last but not least the DLL of course
can just simply be buggy and do stupid things.

So you will have to verify somehow that the DLL works correct outside of
LabVIEW. If you have verified that, then you need to check all
parameters of all function calls into the DLL to be correct and also
large enough for the DLL.

Especially make sure that for strings you allocate 1 more byte than the
longest string the DLL may want to write into, and for arrays that you
allocate the right number of elements of the right type. Sometimes the
documents state that the array must be at least 100 elements long but if
this is an integer then that amounts actually to 400 bytes.

> Also another oddity, when I first open labview and run the code it
> works great, however if I try to close the VI but not labview then
> run it again it fails. I think that labview is not dropping the dll.
> Is there a way to force it to release the dll?

Not really. A DLL should not depend on being unloaded to be callable
again. But the error you describe could be because of several reasons.
Basically make sure you call any existing Close or similar function at
the end as well as initialization function in the beginning. Also the
error could be related to the DLL trashing memory somewhere. So try to
get the DLL to work properly without any bad effects after having it run
once including no crash when unloading the VI, closing any front panel,
doing some LabVIEW edit functions or last but not least closing LabVIEW.

Rolf Kalbermatter
Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
0 Kudos
Message 5 of 6
(3,041 Views)
Rolf has some excellent points that you should investigate in your application. I would first try using the DLL with another application to isolate the problem and determine whether the issue is your DLL or the LabVIEW application. If you can conclude that the issue lies in LabVIEW, then proceed to check and double check your initializations to be sure you have enough space preallocated to the Call Library Node.

Jeremy L.
National Instruments
Jeremy L.
National Instruments
0 Kudos
Message 6 of 6
(3,041 Views)