Memory Leak exe

[EthanHenry]

Hey Y'all,

         I'm at my wits end with this one.  I have a huge project that I'm pretty sure has a memory leak, but I can't seem to find it.  When I run it in dev mode it's unclear whether it's improving or not, so exe is kind of the only way to go.  I've gone through and made a version with lots of case structures so I can turn on and off certain sections of code, and I've started running tests with that.  The problem arises after I've ran it for a while.  At first the memory usage sky rockets, which I guess makes sense as it fills buffers, and then it slows significantly.  After a while of this (30 minutes or so) suddenly it'll drop in memory usage (usually something like 600 MB to 500 MB).  This will continue happening at seemingly random intervals.  Is this drop in memory usage good?  bad?  just a random by product?  Thank you so much, I've been working on this for weeks and I have no clue

[Kyle97330]

I've had similar things happen where the memory suddenly drops.  The only thing I could guess based on my program was that it was one of the external code sections (I had some .NET DLLs and some ActiveX objects being referenced).  If you have any of those you never really know what sort of memory allocation shenanigans they could be up to.

Is your application the sort of thing you can set up to run long-term and monitor its memory usage?  The solution to short term volatility is to get data over a long term and so that you can see a trendline forming.

You also need to calculate whether it's truly worth it.  If you do have a memory leak but it's so slow to grow you can't find it, maybe it takes 100 days of runtime to hit it an "out of memory" error  which is much less of a problem than a leak that takes 1 day to do that.

[EthanHenry]

Yeah It's actually meant to be run for long periods of time, which is sort of a problem, as even a small memory leak will build up to have massive consequences given a couple of months.  How would you recommend monitoring it over a long period of time?  I had a python script that recorded the private memory of the exe every couple of minutes, but all it showed was that the program had sudden drops in memory repeatedly, eventually leaving it at about 80 MB of memory usage.  I'm scared that the script might have started taking memory, push the exe off.

[EthanHenry]

Also, now that I think about it, When closing he application you also get an 0xc0000005 error, and on windows event viewer it shows up as a .NET error.  Could this be important?

[Kyle97330]

---

@EthanHenry wrote:

Also, now that I think about it, When closing he application you also get an 0xc0000005 error, and on windows event viewer it shows up as a .NET error.  Could this be important?

---

Could be?  That's an access violation error and can be caused by many things, including but not limited to usage of .NET or other external code.  In Event Viewer do you get a stack trace that says where the .NET error comes from?  Would be nice to know if it's internal to LabVIEW or to pin it on a specific external file.

One thing you can check is to see if any .NET references you use use the "IDisposable" interface, or other "close/cancel/done" function calls, because just using the standard "close reference" node in LabVIEW may be insufficient to truly tell some 3rd party code that you're done using it.

[EthanHenry]

Whenever I close the exe, I get these 3 errors, all at the same time:

Application: AIRES.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: exception code c0000005, exception address 6644BCB0
Stack:

Faulting application name: AIRES.exe, version: 2.2.3.0, time stamp: 0x5ba1d1be
Faulting module name: lvrt.dll, version: 21.0.0.4000, time stamp: 0x60f02994
Exception code: 0xc0000005
Fault offset: 0x00a7bcb0
Faulting process id: 0x4404
Faulting application start time: 0x01d90c1b43554773
Faulting application path: C:\AIRES\AIRES.exe
Faulting module path: C:\Program Files (x86)\National Instruments\Shared\LabVIEW Run-Time\2021\lvrt.dll
Report Id: 6165fb62-88fa-44c2-809d-a950eccc1c8e
Faulting package full name:
Faulting package-relative application ID:

Fault bucket 1548498271870592300, type 1
Event Name: APPCRASH
Response: Not available
Cab Id: 0

Problem signature:
P1: AIRES.exe
P2: 2.2.3.0
P3: 5ba1d1be
P4: lvrt.dll
P5: 21.0.0.4000
P6: 60f02994
P7: c0000005
P8: 00a7bcb0
P9:
P10:

Attached files:
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.6a219405-6834-4bc7-b1e7-aa6efe79a526.tmp.mdmp
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.90a8a9d8-493c-4bdc-b0e7-043b4d78b623.tmp.WERInternalMetadata.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.4fc61b2b-2dd1-468e-bad7-a897afee7231.tmp.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.ac5863f8-4886-430c-abb7-beba43befe10.tmp.csv
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.49b84678-ff16-4aae-a3e4-1c53901d7430.tmp.txt

These files may be available here:
\\?\C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_AIRES.exe_44d9b1f98257345d5ce12b443e91b3bb09ad59c_2dc54e3d_f161204b-df9b-44ca-9486-b115442954df

Analysis symbol:
Rechecking for solution: 0
Report Id: 6165fb62-88fa-44c2-809d-a950eccc1c8e
Report Status: 268435456
Hashed bucket: a634c9be1efca81af57d5ef95627252c
Cab Guid: 0

as for checking whether a reference uses the IDisposable interface, how would I go about identifying those?  Would the third party software come with a warning? 

[Kyle97330]

If you're using .NET nodes and you put an invoke node down on the reference, an IDisposable object will USUALLY have "Dispose()" listed as one of its functions that you can call.  It's not a guarantee, as sometimes a .NET object wire will be a generic type that can downcast to other types, some of which have a given interface (such as IDisposable) and some that do not.

Do you use a lot of .NET nodes in your program?  

[EthanHenry]

A few, though we used a lot of dlls all throughout

[santo_13]

---

@EthanHenry wrote:

A few, though we used a lot of dlls all throughout

---

It is possible that the memory leak might be in handling .NET references and not in the LabVIEW code, do you have a way to stress test the .NET portion of the LV source code?

[EthanHenry]

I could try but it’s only in a couple of spots. Also I feel it’s important to mention that the memory leak doesn’t SEEM to occur in dev mode, only in exe mode.