Access violation (0xC0000005) at EIP=0x013C7314

[Evan]

I am desperate for some help with LabVIEW 2011 and access violations.  The current one is above.

I have been attempting to use LabVIEW 2011 and recently 2011 SP1 with classes and it just seems to me that they are way to buggy to depend on or even attempt to use.

I am seeing a significant amount of crashes (say 2-3 new ones a day) but each time one crops up it is consistent until I track down what dynamic dispatch or property node is the issue.  I can then make any change to that BD and that crash is gone... until the next one appears.

In addition to the crashes I am getting really frustrated that class property nodes just don't seem to work.  Daily I have to track down a read property node for a class that is simply not returning the correct data.  You can write a double and then when you read it somewhere else you get a huge number.  Again, once I find it all I have to do is select a different item and then put it back and the issue goes away.

I am spening at least 25% of my day tracking down LabVIEW bugs that have nothing to do with my actual code.

So other than ideas on how to get LabVIEW to stop crashing and a need to vent does anyone have any idea how to successfully use a complex large project with classes or should  just accept that LabVIEW is still after all these years not ready for classes?

PS: CTRL-SHIFT-Run arrow also appears to be a great way to waste a ton of time doing nothing, and I have not noticed a difference with the code seperate or together.

[RavensFan]

Evan,  I'm surprised at your post.

As an NI employee, I'd think you'd want to take complaints about the behavior of classes and the "need to vent" to someone within NI rather than put it out on the public forums.

[Evan]

I was an NI employee 3-4 years ago (started in AE then into R&D as a G developer) and have moved on to be a customer of their hardware and obviously their software, but apparently the forums allows you to change your e-mail address (I no longer log in with an NI address) but it does not actually change us to be a "customer".  I have also had issues with the NI sales department about this because my account does not always show the external, and therefore correct pricing for me.

So other than pointing out an issue with the NI forums, do you have any ideas on how to correctly debug and fix the access violations?  I would work with the AEs on this, and have called in about one of the CARs that was fixed in SP1, but I have found that in general the community has great feedback about ways around the issues that LabVIEW R&D either can not reproduce due to the complexity of our projects or the difficulty in showing it in a representative way or it is fixed later, but not in an older version.

At this point I am working on writing 2 scripting tools.  1. Replace all Class property nodes with their correlated subVI, thus eliminating the property node bugs, 2. A tool to change all class properties to a random property and then back, forcing the compiler to actually re-compile.

Do those sound like valid solutions or do you have any other ideas?

Edit: I also arrived at these ideas while talking to an alliance member who also has been facing a rising number of crashes and compile issues where the diagrams of class utilizing VIs are obviosuly not in synch with the real "code" and a force recompile doesn't seem to fix it.  Only a change to the diagram in the "corrupt" section seems to fix it, so it seems to be a compiler issue.  That is why I have played with seperate and non seperate code, and am contimpalting LV 2012, to turn off all the compiler optimizations, however I am not sure if that will actually address the issues.

[Norbert_B]

Evan,

first of all: Did you create a SR directly for the crash(es)?

If re-starting LV, do you send the crash information?

Since i have not seen persistent crashes like this before, i ask you point out specifics of your application. Why is your work prone to those crashes? Is it, because you have so many classes, so extensive class hierarchies? Did you create packages for your classes like PPLs? In short: What is the whole setup?

Did your tests with "seperate source code" bring up any changes?

Are all machines working on the project affected? Can you try out another system (different CPU type, different OS, ..)?

As far as i understand this affects development sources, not a compiled application. Correct?

Norbert

[Evan]

I started an SR the other day for a crash at 0xF50EFD7B, which appears in the SP1 release notes, so I called to see if the CAR had anything helpful as far as reasons and workarounds, but that CAR had no workarounds and no helpful causes.  It is because of that I am evaluating SP1, to see if it is more stable.  To be honest it lasted almost all morning before it started the crashes, but it then took me 3 hours to find the 2-3 property nodes that where crashing and the one possible dynamic dispatch that was the issue.

As far as all the crashes I have submitted some of them through the error reporter (which I also have had hang on me a few times) but have not filed separate SRs, partially because I cannot provide a clear reproducible section of code.  I know how difficult debugging these are and to be honest I have a deadline Thursday, so I can't spend a ton of time trying to help NI finding the source.  That was why I posted here seeing what other developers are seeing and seeing what tricks they have found to get around it.  I can attach or open an SR with the 19 internal error reports I got yesterday if that helps, but I can't say exactly when I fixed one to move on to the next.

I am not sure if it matters but I don't get asked to report the crash on relaunch of LV but right as LabVIEW is dying, and sometimes with the crash window up I can still get into the code or look at a FP for a few seconds to see what I can see.

As far as my project, I am developing on 2 PCs both Windows 7 64 bit, but am using LV 32 bit and have seen this in 2011 and 2011 SP1  I can only run the code on a single machine because the project controls a machine we only have 1 of.  To transfer the code from 1 PC to the other I am using Tortoise SVN, but in general the crashes will start in an area of code that I have not touched, so I can not predict that if I made a change to Class A then that will be the class with the issues.  The overall architecture consists of multiple Queued state machines, where the elements in the Queues are classes.  I get the item off the Queue and then run it's dynamically dispatched "Do" method.

There are currently 7 of those state machines running in parallel.  In addition there is an 8th queued state machine that runs a class subroutine which consists of arrays of other classes.  It then walks though those classes, but it always calls the dynamic functions from within an inplace structure and a Data Value Reference node.

Currently there are a few hundred classes with various depth in inheritance, and I expect to double that number by the end of development.

I have noticed that I seem to get 2 main behaviors.  The software just all out crashes or a property node returns incorrect data.  There are a few property nodes that seem to consistently pass the incorrect data an issue, meaning that if one is going to go bad (which is not everytime I restart the application) they are a good candidate.  For example there is one class with data that is a cluster of 4 ints.  I write to its property node a constant with values 45,2000000,6400, and 3200.  When I then read from the property node on the other side I get values that look the the ints rolled over.  Probing the class going into the property node would show the correct values but the data that comes out would be wrong, so it is something in the property node.  Changing it to a different property and then back fixes it though.

I also have 1 other read accessors that has started to actually crash in the basic accessor code.  I get the error (paraphrased) LabVIEW has stopped in the block diagram of Main.VI->....Read Cal Results.VI (which is the accessor).  And then it opens the VI for me.  Inside that VI is the unbunble by name that LV auto generates for accessors.  A forced recompile and changing the diagram didn't do anything so I now rather than call that code through a property node I call the SubVI directly and the crash stopped. 

I have not noticed a difference with "separate source code" but I made that change in 2011, not SP1.  I will mention that I finally had to write a VI to mark the VIs separate because LabVIEW continued to either hang if done through the project property nodes or it would complain that it could not open the block diagram of the VIs.  However I could then manually open that VI, go the the diagram and then manually mark it separate.  That was another few hours of fun.

I have not tried the code as an exe yet because it is not to that point yet, but the symptoms all seem to be compiler issues so I am not sure if that will matter or simply show new behaviors.

Lastly, I find it hard to believe I am the only one who is seeing the property node and crash issues, partially because I have talked to other developers on completely different projects who also are seeing this style of behavior.  So do you know why a forced recompile would not actually do a clean compile of the code or if there is a different way to do it?  If not, do you think a tool that will go through and switch all the property nodes to a different property and then back would force a compile?  Second, does NI have a tool or something to replace all the class property nodes with their accessor SubVIs or do I need to write it?

Does NI have recommendations about how and when to use LabVIEW classes and the lvclass property node accessors that will help the applications be more stable?  I am concerned that if I cannot trust the property node to return the data of that class that the project will suffer from effectively undebugable issues when I deploy this code to out customers.

At this point anything to help find a solution would be great because I am reaching the point where as I add more classes (meaning more actions and functionality to the project) I have to plan that one of those additions will lead to a few hours of tracking down the new crash locations.

Evan

[mikeporter]

I have had very similar experiences with LV2011. That version crashes - a lot - and it doesn't metter whether you are using classes or not. My most common crash was when creating shift-registers on the sides of loops. I tried the error reporting route but got no definative response, even when I sent them code and specific instructions on how to reproduce the problem.

I originally had 2011 set to prompt me before sending a crash report but that quickly got too disruptive. Eventually I just set it to send the report automatically. The real solution seems to be to upgrade to 2012. My experience so far is that it is MUCH more stable, but as always YMMV.

Mike...

[Evan]

Mike,

Thanks for the reply, it is good to know I am not crazy.  I have not had as many shift register issues, but I also started searching for access viloations and the forums do seem to have plenty of them.

I may have to upgrade, and as expected it is right up against a deadline.  It is that gamble of is the upgrade headache and risk worth the chance that it will be better.

Thanks agian,

Evan

[Evan]

Oh and as a side note it is crashing on load now due to a

DWarn 0xDE90B5AC: typeprop caused typeprop a third time! Give up on: [LinkIdentity "UI.lvclass:Main.vi" [ Main Application Instance]
e:\builds\penguin\labview\branches\2011\dev\source\diagram\proptype.cpp(756) : DWarn: typeprop caused typeprop a third time! Give up on: [LinkIdentity "UI.lvclass:Main.vi" [ Main Application Instance]
minidump id: 14475085-5d37-4359-9780-ad632b605e55
$Id: //labview/branches/2011/dev/source/diagram/proptype.cpp#28 $

I was adding some more refnums to a big cluster of FP references that I pass around. 

2012 is looking more and more likely

[mikeporter]

One more point is to not try and get too "fancy" with the class stuff. Work into it slowly one piece at a time so you can find where the edges of the performance envelope are without a major collapse.

Actually, that's good advice for any new feature that NI adds to LV. Sample the water a bit before diving in.

Mike...

[Evan]

That is partially why I am nervous to upgrade to 2012.  Something to be said for the devil you know, though the fact that we still consider classes and some of their behaviors new after what 5-6 years is somewhat humorous 🙂