OK, not what I was hoping to see. I hoped you could reproduce the issue, so that we could exclude that there are any third-party factors involved. Well, I hoped, but I did not expect to see it
With 20 minutes it was obviously not a complete test (see my PS), but I understand that with the Speak-action problems it might be difficult to continue.
However, your test already seems to point into one direction:
clicking on Enable/Disable group repeatedly does not make the Engine lose memory, at least not continually. It temporarily lost up to 20 MB from the baseline of 44 MB but that seems normal.
Assuming that in normal mode (not safe mode) the issue is clearly reproducible by enabling/disabling groups, it means there is indeed some interdependency with other processes or with some aspects of your normal system setup that triggers the memory leak.
enabling all my other macro groups caused the Engine to accelerate up to 900 MB but then fairly quickly dropped back down to 185 MB. I'm not sure if this is normal behavior or not.
I don’t know either if this is normal, but I would not call it alerting. If memory consumption spikes up for a short time and then drops back to something normal (like the 185MB) I would not speak of a leak in any way.
The KM Debugger rarely responds to my commands.
Do you have to use the debugger? (Did it trigger memory leaks in normal mode?)
I would like to note that in Safe Mode the speakers are completely unavailable
In safe mode all third-party kernel extensions, and probably also any other third-party “drivers”, are disabled. If you are using third-party drivers for your audio normally, then this would explain it.
I guess I can't accurately test the KM Engine until I remove all the Speak Text actions from my macros, which I use as debug statements.
If I recall correctly, you are on an iMac, no? Couldn’t you just switch the system’s audio output to the normal speakers, so that the Speak actions work also without any third-party stuff?
Now you have two possible ways to continue:
-
You take the results of your 20-minutes test as serious. That means, continuing your bug hunt under the assumption that a third-party factor is the trigger for the leak.
- Of course, this makes the whole thing tedious, because isolating the responsible factor out of a few dozens of potential factors is not fun.
-
You try to solve the audio complications (either by eliminating the Speak actions or by making your audio work without third-party drivers), and continue with another extensive safe-mode test, hoping that you can reliably reproduce the memory issue also in safe mode.
- This would be kind of a prove that the bug is a KM-“standalone” bug. Less work for you, more work for @peternlewis
BTW, it seems a bit odd to me that the absence of audio drivers produces such heavy issues (“Speak Text action is failing […] causing the entire Engine to hang up”). Maybe you should tell us more about your audio setup…