Leak bug dynamic call VI without FP

[Bert_INCAA]

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.

[ThiCop]

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.

[Bert_INCAA]

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

[ThiCop]

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?

[ThiCop]

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?

[Bert_INCAA]

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

[ThiCop]

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.

[Bert_INCAA]

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

[ThiCop]

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.

[ThiCop]

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?