There is a likely memory leak which I think is caused by either low or high level analysers which allows the memory usage to far exceed the buffer size until it eventually consumes all the RAM on the computer and either crashes Logic2 or the computer.
Running on Fedora 44 using the AppImage with a Logic MSO
Screencast_20260813_092719.zip (120.3 KB)
The UI is partially unresponsive when it gets in this state. You can’t start a new recording, or navigate the captured trace. The only solution seems to be either close the program or let it crash once all the RAM is consumed.
I haven’t identified the specific events which will cause it yet
I have a suspicion that it occurs when in trigger mode after you have stopped recording but the probes are still attached. When you start recording again I think it is trying to decode all the data that it received while it wasn’t recording
Hi @andrew1, thanks for sending this in, and sorry for the trouble with it!
Can you check to see if the SPI analyzer is still processing while this is happening? just go to the analyzer sidebar and check to see if the progress percentage is still increasing.
High speed SPI can consume huge amounts of memory even over very short captures. The faster&denser the SPI traffic, the longer it takes to process too.
The memory management feature in the software wasn’t really designed with this situation in mind, and it’s on the list to overhaul. Basically, the memory management feature really only cares about 1 thing: while a capture is recording, enforce the memory limit by either (A) trimming the oldest data or (B) stopping the capture, depending on the capture mode used. (Timer captures will auto-stop when they run out of RAM, free-run and triggered captures just trim the oldest data).
Once the capture is stopped or paused, the memory manager system shuts down. So any analyzers that are still running after the end of the capture, or added while the capture is already stopped, have no memory limit. I’m pretty sure that’s what you’re seeing here.
(Note, we have had bugs in the past where the memory manager was unable to prevent memory usage from skyrocketing, because some system in the software still had a read lock on the data and would not allow it to be released. As far as I’m aware, that is fixed)
The real purpose of the memory monitor is to try and prevent users from having a bad time - which is usually in the form of either (A) Our app (or even the whole system) slowing down or grinding to a halt as the OS desperately tries to page memory as fast as we’re consuming it. (generally only a problem while actively recording, because allocations need to keep up with the USB data rate or even faster) or (B) The software crashing due to a allocation failure.
Neither of these conditions can be predicted easily. Item (A) generally only happens when actively recording at a very high data rate. Normally, the system can page easily. this is why our memory monitor ignores other open tabs that are also holding memory - those are likely to have already been paged to disk. Item (B) is also hard to predict. Different operating systems handle this differently. If I recall correctly, MacOS is pretty aggressive about just having allocations fail before the system suffers to badly. I’ve seen some Linux distros completely freeze up before they let an allocation fail.
Enforcing a simple memory limit, even per-capture, is too restrictive in my opinion. If you’re recording slowly enough, the OS can easily page memory to disk to support enormous captures, without any visible performance issues.
The most obvious thing we can do is more transparently report to the user what’s actually happening. We could also measure the rate of allocations (MB/sec), and even measure how long allocations are taking. I think all this information could produce a more accurate picture of the health of the system. The user could then take action if they want their system to run more smoothly, and we could shut things down if things get too bad. (A classic issue is that when the system is paging too hard, it’s not responsive enough to even find and click the stop button. Unplugging the device is the easiest way to stop the problem)