Help dealing with insane objects

[Intaris]

I think everyone's been there before.

Working on a project and for some reason from somewhere an Insane Object appears somewhere in the code.  Not a nice thing to have happen.

At the moment, it's quite a nasty job trying to track these things down.  Usually most users resort to trial and error in trying to find the culprit.  I myself use the mass compile function to at least narrow down which files have the problems.  Recently there was a post on the Forums highlighting the LabVIEW Object Viewer which seems like something which should be much more accessable.

I would like to propose making tools like these more accessable, more usable and maybe adding a tutorial as to how to deal with this.  I also would like to see more sanity checks for the LV code so that we could maybe catch these erros earlier.  How about an error whenever saving a VI so that we can 1) attempt another save in case the error comes from a write error or 2) investigate the problem immediately so that we can rest assured that we have caught the problem early enough to prevent tearing down the whole project.

Message Edited by Intaris on 06-02-2010 02:29 AM

[Intaris]

OK, I really need to revisit this idea.

Let me tell you a story.  Our code involves code on PC, RT and FPGA.  Many VIs are shared among all three platforms.  I have many static inlined classes (no Dynamic dispatch) in the code. and I have some XControls (not coupled with LVOOP).  All is more or less OK.  Except when I close my project.  Then I consistently get a lot of internal warnings.  setstate.cpp, autosave.cpp, projectitem.cpp, xprivatestuff.cpp and so on.

So.  What to do?  I try using Heap Peek (Link in the OP).  Opening the top-level RT VI tells me in the overall statistics that it has 10 vis with bad code.  Hmm, which 10? No idea because it won't tell me.  So I try to do a mass compile to find the VIs with problems.  Oops, LabVIEW crashes.  Even heap Peek crashes if I try to locate certain objects.  My code appears to be hosed.  The mass compile worked once on my RT code and gave a load of insane objects in nirvimemoryEmulation.vi which doesn't even show up in the object list in Heap Peek.

How do I deal with this? Are there ANY NI tools which can effectively help me out here? Even if it means sifting manually through code (It's really a lot of code)?

Why can't we have something which can detect insane objects when loading and tell us WHICH VIS are affected.  Even that would be a great help.

We need SOMETHING in place to stop insane objects in their tracks as soon as they happen.  I have no idea now where to start fixing my code.  That will really cheer up my boss.

[AristosQueue (NI)]

> Why can't we have something which can detect insane objects when loading and tell us WHICH VIS are affected.

Because we don't generally know. A pointer in one VI may look sane ("This is supposed to be a pointer to a string... it points somewhere... is that where it should be pointing? Can't really tell... it looks like binary data, which is a perfectly valid string.") but if that pointer is wrong, writing to it can end up writing over stuff on other VIs. We can tell you which VIs are obviously corrupted, but we frequently cannot tell you which VI is causing the corruption.

Contact your AE and tell them to escalate your code. LV 2011 did improve the reporting of insane objects, but there are limits to that approach. The only NI-internal tools we have for looking at this are a disassembler and time. We don't expect it to happen, we try to guard against it happening, we correct those that we can automatically correct. Past a certain point, it's a bug in LV and we have to dig through the source code to figure out what's wrong.

[Intaris]

The thing which always bugs me is the discrepancy between working with actual code and the results of a mass compile.  It a mass compile can tell me of insane objects, why doesn't or can't the IDE do the same?