LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Issue with crashing VIs in xTab

Solved!
Go to solution

Hi,

 

I have an issue that seems related to the otherwise awesome xTab toolkit from Saphir.
I created an application that opens multiple tab pages, which are really asynchronous running clones of one VI.

When closing a tab with the mouse, I simply receive a user event and then instruct the clone to terminate. This is where things go wrong: as one clone VI terminates, Oftentimes another clone VI crashes and simply disappears. As if the garbage collector thinks that the crashing clone is owned by the one I terminated. This behaviour is pretty consistent, but I cannot reproduce it 100%. If I undock the tabs, the behaviour disappears. However, closing an undocked window can still invoke a docked tab to crash!

 

I created a test project, but haven't yet managed to make that reproduce the issue.

 

Any suggestions, people?

BTW. Is there a way to retreive the owner of a vi ref? Maybe that would reveal that the garbage collector is to blame.. 

 

Aart-Jan

0 Kudos
Message 1 of 12
(4,208 Views)

Spent yet another day on it, but finally achieved some progress!

 

I noticed that a terminating independent VI will kill all xtab async VI references!  This independent VI reads the xTab properties through a global variable of the xtab reference.

 

Using LV2015 32bits

0 Kudos
Message 2 of 12
(4,174 Views)

Got it pretty much figured out:

Any top level VI that uses property nodes that return VI references of the tab windows will subsequently kill those VIs upon termination. That seems pretty nasty. I am not yet sure if there are more property nodes that invoke this behaviour.

 

I cannot reproduce this simply by using the VI references without xTab, so it is not Labview built-in behaviour.

 

Aart-Jan

0 Kudos
Message 3 of 12
(4,168 Views)

Hello Aart_Jan,

As far as you are the first to describe this behavior, I really like to find and fix this issue.

I'm not sure to get the whole picture of your dynamic loading mechanism. Anyway, the behavior you are describing let me think about an issue related to VI Reference lifetime management.

When you create a new tab which part of your code does the dynamic run of the VI displayed in the tab ?

Did you glance at the project example provided with the XTab ? If so does your loading mechanism is really different ?

 

Look forward to hearing from you.

 


Olivier Jourdan

Wovalab founder | DQMH Consortium board member | LinkedIn

Stop writing your LabVIEW code documentation, use Antidoc!
0 Kudos
Message 4 of 12
(4,156 Views)

I use GOOP classes that have an asynchronous VI (the ActiveObject template). Each instance of the class has its own (clone) asynchronous VI that is ideal for creating interfaces in xTab. As these VI's are called by reference, they are top level. When I call one of the before mentioned property nodes in one of these (top level) VI's, all returned VI references will be killed once that calling VI terminates.

 

So it will be easy to reproduce: make a VI that opens some tabs in xTab using a call by reference reentrant VI. Call one of the offending property nodes and then terminate that tab/VI. So I did: see attached example.

0 Kudos
Message 5 of 12
(4,141 Views)

Armed with my new knowledge I was able to remove the bug from my own application. I simply removed the property node Get/Set ActivePage from the code that is running in the tabbed top-level VI or any of its subvi's.

0 Kudos
Message 6 of 12
(4,134 Views)

I glanced at your sample code and reproduce the issue. That's a really weird behavior !

I glance at XTab code call when properties are called and can't figure out why these calls cause other VIs to terminate when aborting the one that did the XTab property call...

Note that the behavior depends on the property called and on the tab position in the XTab. 

 

Question : does the call of XTab properties inside the inserted VI is important for you ?


Olivier Jourdan

Wovalab founder | DQMH Consortium board member | LinkedIn

Stop writing your LabVIEW code documentation, use Antidoc!
0 Kudos
Message 7 of 12
(4,120 Views)
Solution
Accepted by aartjan

@aartjan wrote:

 

I cannot reproduce this simply by using the VI references without xTab, so it is not Labview built-in behaviour.

 

Aart-Jan


And yet you could! The issue lies within the Inserted VI property from the subpanel class.

That super naughty property kind of transfers the inserted VI reference ownership to the VI calling the property node.

So basically in your case, when you use the GetAllViRef property node in one of your pages (that calls into Inserted VI inside the XTab), all the pages VIs are then owned by that very page, so when this latter exits the memory, all the other pages are dumped at that time.

 

I can only echo what Olivier recommends - your page VIs should not know about the XTab and should be pretty much stand-alone. It creates a high coupling between the pages and the hosting VI and in this case messes up with the pages lifetimes.

You have many ways to achieve what you want, one of them would be to send a user event to the main VI that so it returns the information needed about the pages and just forwards them back to the requesting page.

 

--Eric

Eric M. - Senior Software Engineer
Certified LabVIEW Architect - Certified LabVIEW Embedded Systems Developer - Certified LabWindows™/CVI Developer
Neosoft Technologies inc.

Message 8 of 12
(4,112 Views)

Thank you Eric for the highlight (+1 kudo Smiley Happy).

I wasn't aware of this LV "feature" (shame on me Smiley Embarassed)

 

Good day everybody


Olivier Jourdan

Wovalab founder | DQMH Consortium board member | LinkedIn

Stop writing your LabVIEW code documentation, use Antidoc!
0 Kudos
Message 9 of 12
(4,100 Views)

If I can avoid a 2 hours (or way more) headache like I had when I discovered this, then it is my pleasure 🙂

Eric M. - Senior Software Engineer
Certified LabVIEW Architect - Certified LabVIEW Embedded Systems Developer - Certified LabWindows™/CVI Developer
Neosoft Technologies inc.

0 Kudos
Message 10 of 12
(4,093 Views)