Jump to content
mabolas

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

Recommended Posts

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.

post-50257-0-81381400-1412579895_thumb.p

Share this post


Link to post
Share on other sites

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 by mabolas

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

post-50257-0-47358400-1412747620.jpg

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 : )

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.