03-18-2013 03:44 AM
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.
Solved! Go to Solution.
03-20-2013 11:15 AM
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.
03-21-2013 02:58 AM
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
03-21-2013 05:52 AM
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?
03-21-2013 05:52 AM
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?
03-21-2013 06:04 AM
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
03-21-2013 03:23 PM
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.
03-22-2013 02:50 AM
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
03-24-2013 05:04 PM
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.
03-25-2013 06:21 AM
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?