Weird situiation, LV crashed when run to a dynamic property node of object

[mabolas]

I'm new at LVOOP and recently I met a problem confused me ,

the image shows a simple example about it,  and I have no idea how it happen.

 

Did anyone meet this before?

Are there some settings wrong or just a bug of LV?

 

Thanks.

[JKSH]

Hi,

 

What version of LabVIEW are you using?

 

There was a bug in LV 2010 that causes LVOOP property nodes to output wrong data. See issue #255982 http://www.ni.com/white-paper/11869/en/ It was supposedly fixed in LV 2010 SP1.

[mabolas]

Thanks the information.  : )

 

Now I'm using LV2011.

This situation sometimes not just ouput the wrong data, getting worse, it crashed Labview.

 

The erroe remained , crahed LV again and again.......even I reboot the computer......

 

I google the error code(Access Violation, 0xC000005),

seems not only me but happened everywhere.(Maybe not the same, but very similar.)

I'll read more articles to see more discussions about it. 

Edited October 7, 2014 by mabolas

[Rolf Kalbermatter]

Thanks the information.  : )

 

Now I'm using LV2011.

This situation sometimes not just ouput the wrong data, getting worse, it crashed Labview.

 

The erroe remained , crahed LV again and again.......even I reboot the computer......

 

I google the error code(Access Violation, 0xC000005),

seems not only me but happened everywhere.(Maybe not the same, but very similar.)

I'll read more articles to see more discussions about it. 

 

Access Violation is a generic error that is generated by the CPU itself when a code execution causes the CPU to access a memory address that the virtual memory manager does not recognize as being assigned to the current process. Often it is a NULL pointer that is referenced, but any badly initialized pointer can be the culprit. It simply means that something got corrupted in the application memory, but there is no way to determine how it happened from the access violation exception information alone.

[mabolas]

One previous article, almost the same situation as mine.

http://forums.ni.com/t5/LabVIEW/Access-violation-0xC0000005-at-EIP-0x013C7314/td-p/2258546

 

http://www.ni.com/white-paper/13164/en/#213279_by_Category the Issue # 213279, still unsolved.

I'm not sure whether anything related with my problem.

 

Someone helped me test my program with LV2013, and the crash still happened.

I guess somehow the dynamic property nodes being stuck at the previous address of the pointer,

so it loaded the wrong value, or crashed since the address of pointer is no more in computer,

or occupied by other program(maybe OS itself).

 

I just don't understand, why rename the dynamic dispatch property node could save it , and why this problem happened again and again at different class dynamic dispatch property node.

[Rolf Kalbermatter]

One previous article, almost the same situation as mine.

http://forums.ni.com/t5/LabVIEW/Access-violation-0xC0000005-at-EIP-0x013C7314/td-p/2258546

 

http://www.ni.com/white-paper/13164/en/#213279_by_Category the Issue # 213279, still unsolved.

I'm not sure whether anything related with my problem.

 

Someone helped me test my program with LV2013, and the crash still happened.

I guess somehow the dynamic property nodes being stuck at the previous address of the pointer,

so it loaded the wrong value, or crashed since the address of pointer is no more in computer,

or occupied by other program(maybe OS itself).

 

I just don't understand, why rename the dynamic dispatch property node could save it , and why this problem happened again and again at different class dynamic dispatch property node.

 

Are you using any Call Library Nodes in your code? If they are from NI libraries they are likely ok but anything else is suspect. Badly configured Call Library Nodes or buggy external shared libraries have the potential to create exactly such problems.

 

And LVOOP has the potential to be extra susceptible to such corruptions, but unless your LabVIEW installation itself got corrupted somehow is by no means the cause of them.

[mabolas]

Are you using any Call Library Nodes in your code? If they are from NI libraries they are likely ok but anything else is suspect. Badly configured Call Library Nodes or buggy external shared libraries have the potential to create exactly such problems.

 

And LVOOP has the potential to be extra susceptible to such corruptions, but unless your LabVIEW installation itself got corrupted somehow is by no means the cause of them.

Sorry, reply it so late.

No, I didn't use any Call Library Node in this project, it's just a small project for some simple purposes.

 

And, although my Labview installed correctly, your description remind me that once I indeed messed up

Labview itself, it was a bug that caused infinite loop popping out the dialog.

I couldn't press abort bottom, so I had to enforce shutting down labview.

Seems after this corruption, the LVOOP started crashing Labview.

 

Would it cause LVOOP unstable too?

 

Should I recompile all of the programs which LVOOP involved  in?

Or just methods/properties of LVOOP  would be enough?     

 

There's another thing I'm worry about , this is a small project, I could easy rewrite LVOOP or even the whole project itself.

And it also just take a little time to recompile all VIs.

But once it happen to a large project, will there be any better and quicker solutions to save project?

 

Thanks : )