LabVIEW
VC++ code crashes LabView
@Bala L wrote:
It looks like the problem is because of the file operations I perform
to read/write the image. When I remove the file ops in the file-write
function, labVIEW no longer crashes. Also, it looks like file-read is
not loading the image from the file to the memory.
Do I have to change settings somewhere to handle file ops while using
CIN? I did add the CINProperties() function to the CIN code to make
labVIEW recognize my code as being thread-safe. But that hasn't
changed anything.
No special settings should be necessary. Are you sure you allocate the array where you
write in your values inside your C code either explicitedly on the heap or implicitely on the
stack with a big enough size (int array[100] for instance)?
It is most likely something like this that goes wrong rather than functions you couldn't run
from a CIN (I'm not aware of any since LabVIEW doesn't support Windows 3.1 anymore).
Also enabling reentrancy is not making things safer but actually more delicate. If your code
isn't really reentrant safe you can produce anything from a crash to a deadlock or computing
bad data but I would guess this not to be the problem just yet.
Rolf Kalbermatter
@Bala L wrote:
> I allocate memory for the arrays dynamically in the C++ code to hold
> the image. After my calculations, I assign the desired values to the
> function's return variables before releasing the array memory. I am
> pretty certain that the C++ code works correctly since I didn't have
> any memory leaks or weird behaviour when I ran my C++ code in the .NET
> IDE.
>
> A question about reentrancy - does reentrance mean that the CIN
> function is called repeatedly by more than one functions? Or is my
> code reentrant even if other parts of the code are multi-threaded?
If you designate your CIN to be reentrant LabVIEW will call it in whatever thread it is
executing the rest of the diagram. As long as you call that CIN only in one place or can
make sure with data dependency that it is not called in parallel somehow there is
nothing at hand.
But once you call the CIN at different places in LabVIEW that could in fact run in
(pseudo)parallel then you are in trouble when the CIN code or libraries it relies on
are not multithreading safe.
Use of unprotected global variables is for instance inherent multithreading unsafe.
The same applies for static local variables which also are in fact like global variables
in C but with a local scope.
If your code is reentrant (aka multithreading safe) is something only you as programmer
can know. If you tell LabVIEW it is, it will not take any precautions to protect your code
from being called from different places at the same time.
I stil think you do somewhere something wrong. It could be something simple as a
forgotten * dereferencing and most probably when you do source level deugging you
will see it at some point and hit yourself for not having noticed earlier.
Rolf Kalbermatter
As I thought! t_i and T_j are references to integers, but you just assign them with 0 or the cranial and torso integers. Maybe this code would work in a pure C++ program, I'm not sure, but in C it is important to assign the variables correctly.
@Bala L wrote:
"It could be something simple as aforgotten * dereferencing and most
probably when you do source level deugging youwill see it at some
point and hit yourself for not having noticed earlier."
--I figured out why the file wasn't being read properly - I wasn't
assigning enough memory for the file.
I am still having the issue of Labview closing down during a file-
write operation. This is the structure of the C++ code:
// file1.cpp
MgErr CINRun(LVBoolean *start, int32 *t_i, int32 *t_j)
{
/* Insert code here */
func1(start, t_i, t_j);
return noErr;
}
// file2.cpp
void func1(LVBoolean *start, int32 *t_i, int32 *t_j)
{
if(*start == true)
{
CImg img(ROW, COL, FRAMES); // Image object
int torso, cranial;
img.fileRead(INPUT_FILENAME); // Works fine
img.fileWrite(OUTPUT_FILENAME); // Works fine
img.detectShape(torso, cranial);
t_i = torso;
t_j = cranial;
}
else
{
t_i = 0;
t_j = 0;
}
}
The call to detectShape() does all the calculations correctly. At
the end of this function, when I write out an image file with the
detected results, it causes Labview to close down. I tried debugging
the code in the .NET IDE through Labview using the online reference
("using external code in labview" pdf document). The file isn't being
opened correctly, and it is causing the program to exit. The first
fileWrite() is working fine. I'm trying to figure out why this is
happening.
So change
t_i = torso;
t_j = cranial;
}
else
{
t_i = 0;
t_j = 0;
}
}
to
*t_i = torso;
*t_j = cranial;
}
else
{
*t_i = 0;
*t_j = 0;
}
}
instead!
And you probably want to change the torso and cranial parameters to DetectShape to read &torso and &cranial too.
Quite a typical and simple bug most C progammers do in the beginning.
Rolf Kalbermatter
Message Edited by rolfk on 02-13-2007 04:38 PM
