OOP Accessor Data Corruption

[mje]

I'm having trouble where some of my data appears to be...corrupt? See below:

This is an object's accessor method. It really doesn't get much simpler than this. Check the two probes out, one is right before the unbundle by name primitive (#10), the other is right after (#11). Note how the #10 probe shows a value of 300 for AutosaveInterval, which is what it should be. The #11 probe shows a value of 805603042-- no idea where that came from. The VI returns the 805603042 value. I'll also note that the value returned changes each time I run the application.

Needless to say this has completely halted my development, and I'm at a complete loss on how to debug this. As far as I can tell this is the most basic unit of code I can write to access the data in my class. Have any of you ever seen anything like this? Anyone have any ideas, no matter how esoteric?

This is a pretty darn complex application, so I can't exactly extract example code, which is part of the reason I haven't given NI a call already...

-m

[pylb]

Last time I had something like that it happens to be "only" a display issue. So I'll check to see that unit (if used) are all the same, same with the radix.

[jgcode]

What version is this?

Man, if it not a display issue then it looks nasty!

Does a recompile fix it?

[crelf]

Last time I had something like that it happens to be "only" a display issue. So I'll check to see that unit (if used) are all the same, same with the radix.

That's happened to me too - the number on the left was decimal, the number of the right was hex. Not sure if that's you're issue here though...

[mje]

2010 SP1.

It is definitely not a display issue, the returned number is incorrect and causes my application to go absolutely ballistic.

Recompiling the affected VI does not fix the issue. I plan on doing a mass recompile tonight of the entire project (the method is a dynamic dispatch, so other implementations exist which might be causing trouble).

I've also pinpointed the revision which introduced the bug. Interesting thing is the VI is not one of the changed ones, though the class did change.

Behavior persists on two development systems.

More to come later as I unravel this.

[jgcode]

I've also pinpointed the revision which introduced the bug. Interesting thing is the VI is not one of the changed ones, though the class did change.

Probably a good one to send to NI.

Different to your issue, but on the odd occasion I have had VIs that crash in the RTE but were fine in the Dev environment.

Once located, I simply recode them from scratch and the issue goes away.

I have no idea what makes them dirty but its not a pleasant thing to chase down!

[Aristos Queue]

Step 1: Archive your entire application. If any of the following fixes the bug, I would still like the corrupt version archived if you can possibly share it with NI. I don't care how large your application is... if you can share it with us, we'll do the work of extracting and isolating.

Step 2: Load your corrupt VI, do ctrl+shift+click on the Run arrow. Then run your app again. Does problem go away? If yes, proceed to Last Step.

Step 3: There's really only one way that this can happen -- the unbundle node is indexing the wrong memory address. So let's assume that node is actually corrupt and no amount of recompiling will fix it. Delete that unbundle node and drop a new one from the palettes. Run your app again. If that fixes the bug, proceed to Last Step.

Step 4: Still broken? In that case we have to look for something more exotic. Are you using class properties? They're brand new in LV 2010. I haven't heard of anything like this, but newest features are the most likely culprits, so move the accessors out of the property nodes, replace the property nodes with subVI nodes, and let's see if the problem goes away. If it does, proceed to Last Step.

Step 5: Proceed to Last Step, but despair of having a workaround because that's all that I can think of.

Last Step: If any of the previous actually fixed your bug, do File >> Save All and keep working. Please send the archive to NI if you possibly can.

[Mellroth]

I'm having trouble where some of my data appears to be...corrupt? See below:...

Have you tried putting a always copy node after the unbundle node on the numeric wire?

Right before the unbundle node?

/J

[mje]

Haven't tried the always copy idea. Spent a while last night working on this though.

The VI in question also seems to get suck in run mode. Forcing it back to edit mode then forcing a recompile of the VI (Shift + Run) fixes the return value, but the VI still gets stuck in run mode after the application returns. Forcing the entire hierarchy (Shift + Control + Run) to recompile fixes the return value and also resolves the stuck in run mode behavior.

I did a mass recompile of the folder containing the project and all dependencies which also fixes the issue. Several insane object errors were logged, but none of them related to the class hierarchy in question. I will note though that the folder contains some old VIs which have been orphaned, removed from the project but still persist on disk. To some extent I'd expect some errors...

I had come to the same conclusion as AQ with regards to the only way this can happen must be if the unbundle by name primitive is reading the wrong memory address. I've tried editing the VI a few times to no success. Replacing the unbundle by name primitive with a new one, or even a full unbundle did not fix the issue. Several times while attempting to edit the VI, I get a LabVEIW crash:

Interesting indeed. I have yet to find a pattern in the returned number. I've been trying to see if the memory is offset by a few bytes in either direction, but have yet to get anywhere with that.

Answering some other issues:

The object in question is actually contained in a data value reference. Data access is done exclusively through property nodes. What can I say, I'm lazy: property nodes are way easier to deal with than dropping an IPE with strings of VIs each time I want data.

I examined the revision deltas more closely, and neither the method nor the class has been edited between the last stable revision and the one which introduced the bug. The library which contains the class though has. I misspoke earlier about that, my apologies (the library bears a similar name to the class and I misread the logs).

Given that the VI and class had not changed when the error triggered, I have a sinking feeling this issue is not related to the code for the accessor, but more indicative of an in-placeness bug, possibly relating to synchronization.

Not to derail this topic, but I have seen other bugs in the IDE relating to IPE-DVR structures. Have any of you ever tried debugging code which a single VI is in an IPE-DVR structure, and it is impossible to step into that VI? Even slapping a breakpoint in the VI doesn't work, which worries me. Haven't been able to gather much info on that one, but I've seen it many times. There's something funky going on with the in-place algorithm that I think might be the reason behind these issues, but I don't wish to dwell on conjecture and would like to keep focused on the original topic.

I've produced an archive of the affected code. I removed all the builds etc and the bare code turns out to be quite small (~30 MB). AQ thank you for your interest, I'll contact you privately to figure out how best to get you the code.

-michael

[mje]

So I've been speaking with NI (thanks AQ and Mike!) and the issue has been resolved. It is a manifestation of the same issue reported by Jon Kokott (CAR 255982).

The issue actually turned out to be in another VI further up in the call chain. This VI was missing a link to another property defined in a base class, which resulted in the VI's data not being set up correctly. The bad data was then passed to the accessor method shown in my original post which would read garbage data. Performing an explicit recompile of the affected code under LV2010 SP1 fixes the problem.

The gory details: The data structure in question is interesting and I believe actually sheds light on why the problem wasn't so quick to go away. The relevant hierarchy is as follows (if you can make sense of the mashup of pseudocode and UML):

namespace LabVIEW.Messaging.2.0.lvlib{ 	class Application.lvclass    {        property Timeout        {            public <<Dynamic>> ReadTimeout(inout App:Application, inout Error:Error, inout Timeout:I32)        }        public Run(inout AppRef:DVR<T->Application>, inout Error:Error)    }}namespace MyLib.lvlib{    class MyApp.lvclass : LabVIEW.Messaging.2.0:Application.lvclass    {        property Timeout        {            public <<Dynamic>> ReadTimeout(inout App:MyApp, inout Error:Error, inout Timeout:I32)        }        property AutoSaveInterval        {            public ReadAutosaveInterval(inout App:MyApp, inout Error:Error, inout AutosaveInterval:I32)        }    }}

If you refer back to the original post, the screenshot of the code would have been from MyLib.lvlib:MyApp.lvclass:ReadAutosaveInterval.vi.

The offending VI was Application:Run, it was missing a link the Application:Timeout property. The Application:Run method read the Timeout property via the Application DVR passed to it. Using the property will ultimately call MyApp:ReadTimeout due to the dynamic dispatch, which in turn calls MyApp:ReadAutosaveInterval. The call chain would therefore be:

LabVIEW.Messaging.2.0.lvlib:Application.lvclass:Run.vi

MyLib.lvlib:MyClass.lvclass:ReadTimeout.vi

MyLib.lvlib:MyClass.lvclass:ReadAutosaveInterval.vi

Things to learn from this:

• Recompiling the VI which showed the problem (ReadAutosaveInterval) did not reproducibly fix the problem because it was only a symptom of the problem.
• The symptomatic VI was actually fine: when running it alone or in isolated test cases, it behaved as it should.
• Recompiling the hierarchy such that Application:Run is recompiled fixes everything since it is the offending VI.
• If you see a problem like this, work your way up the call chain to see if there are any VIs which are being left out of your recompile.

Cheers,

-m