genericmgr.cpp error in line 775

[Jonas Van Otterdijk]

Hi,

Labview crashes sometimes with an genericmgr.cpp error (line 775). I can't isolate the problem but I've got a feeling that it is about IMAQ.

I've seen it on 2 different machines.

Can someone pleas help me to put me in the right direction to find the solution?

Kind regards

Jonas

[Riggy]

Hi, would you mind if I add to this myself? I am using IMAQ and recently altered my code, now I get exactly the same failure and message (Win2000Pro). It began when I started using a new .vi called "IMAQ Remote Compression.vi" from the NI website, but I can't seem to isolate the actual problem.

Riggy.

[nipun]

Hello Jonas and Riggy,

How often do you see this error? Is this something that is easily reproducable? Do you get this error when running a particular vi? From the error message I noticed that you were running LabVIEW 7.0, but from the error report it does seem like you have LabVIEW 7.1. Do you see the same error with LabVIEW 7.1? Have a great new year!

Nipun M.
Applications Engineer
National Instruments

[Riggy]

Hi nmathur,

I can't speak for Jonas, but I am certainly running LV7.0 on Win2kPro.
I am using a bunch of vi's designed to take images from a webcam, compress them using JPEG, send them over a TCP connection to a receiver that decompresses and pastes them to a picture window.

Complicatingly, I had problems with the JPEG Encode and Decode vis, as they were causing severe memory leaks, and with some help from Peter Horn (Apps Eng' at NI) I started to use the Remote JPEG Compression vi instead. This solved the memory leak problem, but recently created this totally new crash issue.

Included are the set of vi's that capture, compress, transmit, decompress and display, but I don't think you'll be able to execute them without the huge array of other vi's that they work with. I apologise for the shoddy code, I'm not a professional programmer 😕

Thanks for your attention,

Riggy

[nipun]

Hi Riggy,

Is the Image_receive.vi running on a real-time machine? If you run the Image_receive.vi in Highlight Execution mode do you see LabVIEW crash when Remote Compression VI is called? Have you tried to remove remote compression.vi from your code and run the VI. Please try these tests and let me know what you observe.

Thanks,
Nipun

[Riggy]

Hi Nipun,

Ok, here's what I have discovered so far:
1) I'm not sure what you mean by a real-time machine, but all the vi's are built into an executable application and run on an ordinary desktop PC (Win2kPro). The error still occurs when the vi's are run through LabView though, so I don't suspect the error to be compiled-version-specific.
2) Remote Compression.vi does not seem to be the problem. I believe this to be the case because the vi's all run without problems. That is, until a TCP connection is established between the two running sessions of LabView. Previously, this has never presented a problem. Only now, with the recent changes, does making a TCP connection somehow cause a problem. To complicate this further, I ran the programs again today, and the crash occurred after 10 minutes of successful operation (with a TCP connection established and images being passed between the two computers). Could this indicate a memory leak issue, or some backlog of TCP data?
3) I have today seen conflicts in the way images are accessed. To explain, both PCs run the same vis. Each acquires images from its own Webcam. The vi's are designed to display their own images when no connection is established, or display the images received over TCP when a connection is established. After starting the programs I saw each PC displaying the images of its own webcam, then, after connection, they switched to displaying the received images. This is how they should work. Occasionally, however, images from the PC's own webcam would show on screen, indicating that (my faulty code notwithstanding) somehow the programming is able to access the IMAQ images reserved for upload. Could there be a handle problem?

This may be related to IMAQResample: Using a probe to inspect the ImageSrc and ImageDst during operation shows a discontinuity, ie the "image in" is the same as that received from the TCP connection, but the "image out" is actually that from its own Webcam. How the vi manages to intermittently switch the images is something I don't understand.

This does not explain the error though, and may be totally unrelated.

I have yet to try removing the remote compression vi from the code.

Riggy.

[Riggy]

OK, i have more.
It seems that IMAQ Remote Compression.vi has a problem (or I'm using it entirely incorrectly!)

I have two vi's that use it: Image_Grab.vi and Image_Receive.vi
The first creates a single IMAQ image, title "Captured".
The second creates an array of 10 IMAQ image pointers, each titled Buffered0, Buffered1 ... Buffered9, and another single IMAQ image called InsetImage.
After running the vi's, it would seem that the array of IMAQ images have actually become titled: Buffered0, Captured, Captured... Captured. !!!
For some reason there is a conflict between the images. This explains why some of the images seen on one machine match those from its own camera when it ought to be displaying only those received from the TCP connection.

Can you perhaps see where my code is causing the conflict? Or is my application of Remote Compression.vi incorrect, ought it only refer to one image throughout the entire code?

Riggy

[nipun]

Hello Riggy,

Thank you for your reply, a real-time machine is a special controller running ETS real time operating system to add more determinism.

I spent some more time looking at the Image_grab.vi, I see that you are using global variables to pass data between VI's. It is hard to maintain synchronization using global variables. It is possible that you read from that global before it has been written to. If you are using a global variable to determine which image to display, or to pass images between vi's that could be causing the problem. If you are displaying single frames at a time make sure you have snapshot selected for your IMAQ display. To enable snapshot, right click on the IMAQ display and select snapshot. I'm not convinced this problem is causing the LabVIEW crash.

Increase the wait in the loop of the image_grab vi and see if that fixes the problem or increases the time before you see the crash. Are you still seeing a memory leak with this VI? Look for an increase in the amount of memory being consumed in the task manager window.

Nipun

[nipun]

Hello Riggy,

I will look through the VIs. In the mean time can you remove remote compression vi and see if that changes things?

Nipun

[Riggy]

I have tried many things recently, including an upgrade of IMAQ version to 3.00 from the NI web pages.

Globals do not appear to be the problem (after several hours removing any reference to globals by diminishing the code), but I can report that the error has not reoccured. I believe this to be a direct result of the upgrade to V3.0 of IMAQ. I know this because I was able to upgrade my LapTop on Wednesday, which has not encountered the error since, but my dekstop only today, which was encountering the error.

Now the code run without the error. I do, however, have a recurrance of the memory leak issue that I once had many months ago, although I believe I know the cause: A part of the code flattens a IMAQ image into a data type and string. Later, this string is reconstructed back into an image and into a different IMAQ buffer. At this part of the code the memory allocation increases. I believe that this process causes the memory increase. I am currently trying different solutions.

Riggy