LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Leak bug dynamic call VI without FP

Solved!
Go to solution

While debugging a memory leak in our application I discovered this leak.

It turned out it wasn't our problem in this project, but it is nevertheless a unwanted situation.

 

I made a example project for demonstrating the discovered leak.

The following combinations are possible:

Remove FP (default) + don't show FP when called (default) = leak

Remove FP + show FP when called = no leak

Don't remove FP + don't show FP when called = no leak

Don't remove FP + show FP when called = no leak

 

The problem is demonstrated and discovered in LV2011, but also appears in LV2012.

 

0 Kudos
Message 1 of 16
(1,872 Views)

Hello Bert,

 

Can you give some information about how big the leak is at your side after a specified amount of time?

This will allow me to check if the behaviour I'm seeing is exactly the same as yours.

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 2 of 16
(1,823 Views)

Hello Thierry,

 

The not leaking version stays around the 23 MB memory use.

The leaking version first grows rapidly and then steadily slower, but eventually it stops with a memory full notification (around 3,8 GB memory use after night running).

 

After 1 minute = 380 MB

After 2 minutes = 405 MB

After 4 minutes = 430 MB

After 10 minutes = 6MB per minute

 

Kind regards,

Bert

0 Kudos
Message 3 of 16
(1,806 Views)

Hello Bert,

 

I saw another post of you in the last days:

http://forums.ni.com/t5/LabVIEW/FGV-in-packed-lib-cause-leak/m-p/2357364#M735319

 

Are both of them linked together?

Or did you retrieve this from that issue?

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 4 of 16
(1,799 Views)

Hello Bert,

 

I saw another post of you in the last days:

http://forums.ni.com/t5/LabVIEW/FGV-in-packed-lib-cause-leak/m-p/2357364#M735319

 

Are both of them linked together?

Or did you retrieve this from that issue?

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 5 of 16
(1,798 Views)

Hello Thierry,

 

In our project appeared a problem. On the search for that problem I found this problem.

After some research I found out this wasn't our problem in the project, because the sub-vi is there "Always included" which removes the checkmark from "Remove FP", and without that checkmark this problem doesn't occure.

 

The problem reported in the other topic was found after further research after finding this problem. It's not related I think, the symptoms are different. And the structure too. The only similarity is the dynamic call.

But this problem is leaking much faster and more than the other problem. And this problem gives a "memory full" error and the other problem a "attempted recursive call" error.

 

Kind regards,

Bert

0 Kudos
Message 6 of 16
(1,794 Views)

Hello Bert,

 

It remembers me of a Corrective Action Request I opened at the end of last year.

Did you ever see any memory leak in the development environment (a small one even) itself?

 

I see some increases (in development environment), but it has a very slow upward trend.

 

In the executable the behavior is indeed clearly visible.

 

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 7 of 16
(1,784 Views)

Hello Thierry,

 

The two bugs/issues I reported were seen and searched in the executable (as in the project were it showed up).

In the development environment I don't see a leak as in the executable, indeed maybe very very slow.

 

Kind regards,

Bert

0 Kudos
Message 8 of 16
(1,776 Views)

Hello Bert,

 

Tomorrow at the office I'm going to check if this issue might be link to a similar issue with dynamic calls that should be resolved in LV 2013.

I need access to some internal database that I don't have on this pc.

 

I'll let you know.

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 9 of 16
(1,757 Views)

Hello Bert,

 

I did quick check here and it seems like it's not the same issue (different options selected).

When I do my validation test of the other issue in the newest build of 2013 I'll also test this in there

 

Next to this I have on other question.

Based on th options it seems like you want to asynchronously call the VI.

Is there a specific reason why you used the Run VI method instead of the Asynchronous Call Node?

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 10 of 16
(1,739 Views)