DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

DQMH Request Create Notifier and release notifier for every request, will it cause memory leak

For Request DQMH Obtain Notifier and Release Notifier for every request will it cause memory leak over a period of time. When Does LabVIEW deallocate memory? Does it deallocate memory immediately once we Release Notifier?

 

0 Kudos
Message 1 of 7
(1,042 Views)

Hello LV_COder, thanks for bringing this up.

 

The short answer is "No, requesting a notifier reference and releasing it will not cause a memory leak over time. Memory will be returned when the reference gets released. This is why this design was chosen."

 

There is no long answer 🙂

 

Spoiler
Edit: Well, maybe a little elaboration is helpful. AFAIK, LabVIEW will usually not immediately free memory after a resource finishes, to avoid having to reallocate memory again for the same resource. Think about a Request VI: LV will allocate memory the first time the VI is run, and will keep the memory allocated. The next time you run the VI, the same chunk of memory can be reused. This is how it works, as far as I know, in layman's terms. Anybody, please feel free to correct me if I'm wrong.



DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


Message 2 of 7
(1,004 Views)

Thanks, I have heavy reply payload, though using DVR, I have observed 2 times that memory is getting increased from 1gb to 3gb gradually, then suddenly from 3gb around it drop back to 1gb. Not Sure about this behavior. Code has been running for maybe 12 hours around, Any Suggestions 

0 Kudos
Message 3 of 7
(974 Views)

It's something related to garbage collection? but still growing around 2Gb is huge.  

0 Kudos
Message 4 of 7
(917 Views)

If your reply payload is a DVR, then the allocation to the actual data value shouldn't be affected by the use of the notifier. The data value may be gigabytes in size, but the DVR is only ever 32 bits. That's not going to cause an issue. I wonder if instead you should be investigating the data value itself, and places in your code where perhaps you are accessing that data and growing its size, making a copy, or something else.

 

Joerg is correct about allocation. Just because you call Release Notifier, Destroy Data Value Reference, Release Queue, Close Reference, Close File, etc. etc., doesn't mean LabVIEW immediately releases that memory. The LabVIEW Memory Manager decides on its own when it makes sense to deallocate because, again, as Joerg mentioned, things can be much more efficient when LabVIEW reuses memory that is already allocated. Sometimes people think they can call Request Deallocation to "force" LabVIEW to deallocate memory. But again, the LabVIEW Memory Manager is the ultimate decider... the function says 'Request' for a reason. 

Message 5 of 7
(910 Views)

Hi Darren, Thanks for the explanation, nowhere I am making copy or branching wire after reading from DVR.

Its repeatable now that memory is growing till 2Gb or 3Gb then dropping back to 1Gb. As it is getting back to 1Gb around always then definitely it's not memory leak, I think.   

Is it something with LabVIEW garbage collection or anything else?

0 Kudos
Message 6 of 7
(899 Views)

LabVIEW doesn't have a garbage collector. It has a memory manager, as described in the link in my previous reply. The memory manager decides when to allocate and deallocate. There is something happening in your code causing the memory usage to grow, and then at some point when that memory is no longer needed, the memory manager is deciding to deallocate. There are profiling tools in LabVIEW that you could try (Profile Buffer Allocations is probably where I would start, it's in the Tools > Profile menu) if you are really interested in narrowing down where the large allocations are taking place.

0 Kudos
Message 7 of 7
(896 Views)