12-14-2022 05:45 PM
Sorry for the silence, I recently found that the exe I've been using wasn't behaving how I thought, so I've had to build a new one, which has taken, and still is taking, a couple of days. I'll update you once I've gotten the build up and running with any new information I get. Thanks again!
12-15-2022 02:48 AM
Feel free to post the code or snippets of it.
You wouldn't be the first to miss a .NET reference to close or some CFLN memory allocation to deallocate.
12-16-2022 11:18 AM
It's a bit hard to show code snippets as the project is ginormous, however I do think I've narrowed it down to this part of the code (ignore the case structure that's just me trying to find what part of the code was causing it).
My first thought is if the limiting of the array using this method is causing a memory? I looked online and it seems like, for a circular buffer, a queue with fixed size and lossy enqueuing works, but I haven't heard anything about this array subset. Anyone have any ideas as to what may be the issue here?
12-19-2022 02:50 AM
Pretty sure that won't leak. Not sure about the SubVIs, obviously.
The array isn't working as a circular buffer though, it's just an array that is moved over and over again so it has room to add elements in front of it.
So it won't be performant, as the array is continuously recreated. Which is OK if it doesn't need to be fast (or if it's fast enough).
A queue works, but you'll be working by reference and AFAIK peeking for the elements will always make a copy of the data. A pure 'value by wire' can avoid those copies, although it can be very hard.
12-19-2022 03:57 AM
@EthanHenry wrote:
...so I've had to build a new one, which has taken, and still is taking, a couple of days.
Jesus christ.
What do you do if build fails? Silently weep?
12-19-2022 10:54 AM
Yeah, kinda… 🥲
mice found a pretty reliable way to build, so hopefully I’ll be able to iterate faster now
12-19-2022 02:06 PM
Yeah testing it out it seems to be one of the sub VI, I'll try it and tell you how it goes
12-20-2022 03:39 PM - edited 12-20-2022 03:59 PM
Ok no definitive evidence yet, however I went through the logs again and found something else interesting. About 12 hours before the resource exhaustion warning there was another resource exhaustion alert, this time listing niroco.exe as the highest contributor. It seems to continuously grow then gets terminated unexpectedly, and doesn’t seem to appear again. I’ve started tracking it on the program and it does seem to increase as time goes on. What is this used for? It also seems to not reduce in memory size between runs of the exe. Also, opining Resource Monitor and going to it and analyzing the wait chain shows 4 threads, which it says are waiting for network I/O?
12-20-2022 04:00 PM
@EthanHenry wrote:
Ok no definitive evidence yet, however I went through the logs again and found something else interesting. About 12 hours before the resource exhaustion warning there was another resource exhaustion alert, this time listing niroco.exe as the highest contributor. It seems to continuously grow then gets terminated unexpectedly, and doesn’t seem to appear again. I’ve started tracking it on the program and it does seem to increase as time goes on. What is this used for? It also seems to not reduce in memory size between runs of the exe. Also, opining Resource Monitor and going to it and analyzing the wait chain shows 4 threads, which it says are waiting for network I/O?
National Instruments ROute COordinator. Coordinates signal routing on NI hardware.
12-20-2022 04:06 PM
Hmmm I'm not using any NI Hardware right now, is there any reason it'd explode in size? Windows logs reports that at one point, before it crashed, it was at about 4 GB of memory usage