Access violation during IMAQ to variant conversion

[amounier]

Updated VI with a better fix.

I couldn't just create images and unalloc everything at the end as propose.

Respective objects have to unalloc images they created, and, at the end, I use IMAQ "All images" option to dispose residual images due to memory problem.

This solved "Variant crash". I had to add a reset of display before unallocation to solve "Update by reference crash".

[jqu]

Hi folks!

I'm getting this kind of exception for months now in a rather complex application.Now you finally pointed me in the right direction, what to look for. I want to share the following insights with you:

1. I think using the value property node has the same effect as "to variant" because of the "coercion dot".

2. With the latestest "fix" I observe the following: "Variant crash test" works exactly ONCE with the default settings. If I run the VI a second time, I get a crash. It also crashes on the first run if I increase the number "Images #1" by only one. The other numbers I can increase without any effect. "RefValue crash test" always leads to the access violation. To conclude, this is not really a fix for me.

3. I never observed any difference when using "Clear all images" during dispose.

4. I can run the very first example from this thread indefinitely often *if* I put an additional "Create image" - "Dispose image" at the very end. I.e. no crash in this case at all. However, this "fix" does not work for the "_fix" version posted in the previous message. The reason here is the "Variant to data". When I remove that part, the fix works again. I realize, this is completely useless if you cannot convert the images back from variant, but maybe it helps somebody to finally debug this issue.

5. It seems that using "type cast" to convert an "image" (reference) to string is the easiest and most harmless method to arrive at a generic data type you can toss around without knowing what it is. If you like, you can even convert the string to variant, then back to string and finally type cast back to image. I never observed the access violation with this method.

Cheers,

jan

[CAPTIC_LA]

Hi everybody,

Since too many days (maybe weeks) I'm pulling my hair out of my head on the same issue, and I just discovered your post explaining it exists for a long time :-((

I was trying to upgrade my Vision application from "LabVIEW 2013 SP1 + Vision Dev Module 2013 SP1" to "LabVIEW 2016 + Vision Dev Module 2016" and I had the same crash...

I also store several references to image display controls and display images through property nodes and it crashes when the main VI of my app stops. It does not crash if I don't free allocated images!

I can confirm that even the "_fix" VI also crashes for me... and not with LabVIEW 2013 + VDM 2013 (once the VI converted to 2013)!

It is just impossible for me to upgrade to 2016 with this bug.

Does anyone know an efficient workaround?

Thanks for your help

[jqu]

Hi CAPTIC_LA,

I'm not quite sure I understand correctly. Problems started after upgrading from 2013 to 2016, or persisted despite the upgrade?

Anyway, so you use a lot of code like this?

Notice the red dot on the input of the property node. It means this is essentially equal to this:

which is believed to cause the discussed issues.

In my case it helped to use this instead:

May be a dirty solution. I don't know. But I use it a lot to store image references in places where I need the flexibility of the variant type.

hth,

jan

[CAPTIC_LA]

Wawh! Thank you JQU!! It Works!!!

I attached the new version of the VI showing the crash but with the correction using your workaround (Type cast, only for "RefValue" crash).

I also tested in my Vision application and it seems to be OK. For sure I have deeper tests to do since it is a large application with many functionalities but that's a great news. Thank you again.

[jqu]

That's great news! Very pleased I could help

Kudo much appreciated, thanks!