LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

FGV in packed lib cause leak

Solved!
Go to solution

Hello Thierry,

 

For which version do you want the source code? And how?

 

Norbert tested the demo with LV2012 and could reproduce the error (all source available in zip).

 

The snippet contains the only VI in the packed lib. The main VI calls the subVI (old method run vi, auto dispose ref) and the only thing in the subVI is a call to the VI in the packed lib without options.

 

Kind regards,

Bert

0 Kudos
Message 11 of 28
(424 Views)

Hello Bert,

 

As long as it is a version that shows the issue at your side it's ok for me.
I can work from there.

Kind Regards,
Thierry C - CLA, CTA - Staff R&D Engineer, RF Semiconductor Test - National Instruments
If someone helped you, let them know. Mark as solved and/or give a kudo. 😉
0 Kudos
Message 12 of 28
(410 Views)

Hello Thierry,

 

I made the conversion to 2012 with a more correct implementation of error handling.

 

Kind regards,

Bert

 

 

 

0 Kudos
Message 13 of 28
(399 Views)

Hello Bert,

 

Thanks for the files.

I'm now first trying to reproduce it.

I'll also give it a go in the new LV 2013 beta I have running on another pc to check if it might be linked to another issue I have reported.

Kind Regards,
Thierry C - CLA, CTA - Staff R&D Engineer, RF Semiconductor Test - National Instruments
If someone helped you, let them know. Mark as solved and/or give a kudo. 😉
0 Kudos
Message 14 of 28
(385 Views)

Hello Bert,

 

I did several tests at my side with the Run VI as well as the Asynchronous Call and all of them gave the same issue with this .lvlibp. (2012, 2012 SP1 and 2013)

 

Do you encounter these issues with any other type of library?

With the .llb you didn't seem to have any issues, right?

Kind Regards,
Thierry C - CLA, CTA - Staff R&D Engineer, RF Semiconductor Test - National Instruments
If someone helped you, let them know. Mark as solved and/or give a kudo. 😉
0 Kudos
Message 15 of 28
(377 Views)

Hello Thierry,

 

We indeed did a quick check with the asynchronous call and the memory increased too (we didn't had time to wait if it was exactly the same), so we made a fix with another structure.

 

The old version in LV2009 with an LLB didn't show this problem at all, but it was not handy for replacing the llb without rebuilding the application (it worked, but not easily).

 

We haven't had such problems with other types of library's or with this library in another application (no dynamic call with linkage to this library).

 

Kind regards,

Bert

0 Kudos
Message 16 of 28
(373 Views)

Hello Bert,

 

My apologies for the delay.

 

This week I was Out of Office so I could not do any further tests.

 

Can you tell me a bit more about the "fix with another structure"?

 

 

Kind Regards,
Thierry C - CLA, CTA - Staff R&D Engineer, RF Semiconductor Test - National Instruments
If someone helped you, let them know. Mark as solved and/or give a kudo. 😉
0 Kudos
Message 17 of 28
(355 Views)

Hello Thierry,

 

The original structure worked like I described: for each request (for posting measured data) a task is spawned.

So also when there is constantly 1 device posting data, for every new post a new task is spawned.

In the new structure there is one task spawned per "posting device" which handles all requests for this device. A drastic reduced number of spawned VI's which solved the problem..

 

Kind regards,

Bert

0 Kudos
Message 18 of 28
(345 Views)

Hello Bert,

 

Thanks for the feedback!

Were there any other tests in the meanwhile or should I just continue from where I left off?

Kind Regards,
Thierry C - CLA, CTA - Staff R&D Engineer, RF Semiconductor Test - National Instruments
If someone helped you, let them know. Mark as solved and/or give a kudo. 😉
0 Kudos
Message 19 of 28
(331 Views)

Hello Thierry,

 

On my side there has no further testing been done, and I didn't got feedback from others testing the issue if there are..

 

Kind regards,

Bert

0 Kudos
Message 20 of 28
(326 Views)