Print statements hanging Hammerspoon and triggering memory leak #3565
Comments
|
I've been having the same issue. Tried running your code for a couple minutes, and indeed HS hung and its memory usage suddenly shot up >1GB and rising. Looks like a CPU issue. Here's the start of the issue per the console: |
|
Also have been running into this issue, my hotkeys suddenly stop working and memory usage starts increasing rapidly (usually I catch it at ~10-50 GB but just now I only noticed it at several hundred GB). I only have one print but I guess it's triggered on every focus change, I'll try removing it. Though HS also prints stuff every time hotkeys get enabled and disabled, which also happens quite often for me, hopefully that doesn't matter, since |
|
Can confirm the issue here. Indeed if Toggling hotkey use the same function as print, I don't really have any workaround for that. For now I'm trying hs.console.maxOutputHistory(1), w/ a custom code to rewrite console to file hammerspoonLogFile = assert(io.open('hammerspoon-console.log','a'))
hammerspoonLogFile:setvbuf("line")
-- Override Hammerspoon's print with print that logs to file, not just HS console
-- See print() definition in https://github.com/Hammerspoon/hammerspoon/blob/master/extensions/_coresetup/init.lua
local old_print, tostring = print, tostring
local tconcat, pack = table.concat, table.pack
print = function(...)
local vals = pack(...)
for k = 1, vals.n do
vals[k] = tostring(vals[k])
end
local l = tconcat(vals, "\t")
hammerspoonLogFile:write(l, '\n')
return old_print(l)
end |
It's not documented1 (Edit: yet - see comments below), but there's actually an (Also, by default, entering/exiting an Footnotes
|
Thanks, As for modal, indeed no message is shown. |
|
Related: Add setLogLevel documentation for each extension #2248 |
|
Whoops. I just realized how recent that commit I linked was - it's not actually in a release yet, so of course it's not showing up in the documentation. |
|
Thank you for this report, I've run into the same "mysterious" freezing issue for a while, although I did not really change my configuration. I've removed a lot of logging from my codebase and hopefully, this should lessen the issue. |
|
FWIW I had the same issue, reduced logging to almost nothing and at least it's not crashing anymore. Would still like to be able to get my logging back though. ;] |
I have created a helper to disable the logging for some hotkeys: |
|
Same issue. |
|
Same issue for me! and this seems only happens on apple silicon not intel based mac, any suggestions up to now? |
|
FWIW this is happening on my Intel Mac. I did manage to mitigate it by reducing the print/logging statements to almost nothing. |
|
So the behaviour here is really interesting. With the default console history length of 100,000 characters, I can also reliably repeat the hang using @gab-john 's test snippet, after about 2100 iterations. Dropping the history length to 50,000 characters raises the hang point to about 38,000 iterations, by which point Hammerspoon is using 20GB of RAM. I think it's pretty clear that the current methodology for truncating scrollback is a complete disaster that will eventually fail at any length limit (although it looks like the scaling is non-linear, so a limit like 5,000 ought to hold crashes off for a very long time) because something is leaking. I've quickly profiled a debug build and it looks like the majority of the RAM allocations are coming from text related classes in AppKit. So, this is either a generic bug in AppKit that eventually an infinitely growing NSTextView will just hang, or there is something more subtle going on. One hypothesis I had was that because we just delete characters off the front of the underlying NSTextStorage, we would be confusing the fact that they were added as NSAttributedStrings, but I don't think that can be it because the hang doesn't seem to be happening very close to where that happens. I'll keep poking at this and see what I can come up with. |
|
Ok, I've restructured the way text is written to the console, and it will now be batched up and only actually committed to the NSTextView every 0.2 seconds. I've also changed some settings on the NSTextView to turn off a lot of the fancy things that make no sense for a log viewer (things like spell checking) and while I'm not super happy with the RAM usage, the situation overall appears to be dramatically improved. After 20,000 iterations of the snippet, with the default 100,000 character history limit, Hammerspoon is still running fine, and RAM usage has "only" grown to 1.9GB. I suspect there is still a hang lurking out there in the future, but it should now be far less likely to be hit in any reasonable session. I'll push the code up shortly and I'm hoping to get a release out in the next couple of days. Thanks all for your contributions here, and apologies it's taken so long to address! |
…se leaking/hanging when lots of output is happening. Fixes #3565
Hello, after I've upgraded from Sonoma 14.0 to 14.1, my script stops responding a few times a day. Hammerspoon becomes unresponsive, the console becomes blank, and the memory starts increasing indefinitely to several GB.
I've worked around the issue by removing all print statements, and now it no longer crashes, but I spent some time anyway trying to isolate the reason.
This snippet should reproduce the issue when pasted on the console:
On an M1 and on an Intel (both Sonoma 14.1), it hangs after 2000-3000 iterations.
Interestingly, it doesn't happen if all the strings after some point are the same length, such as with just
print(i). Then it crashes a few numbers after10000(becauseichanged from 4 to 5 digits). That holds true even ifistarts at-1000or-5000, it would still crash a bit after10000.It also doesn't happen when disabling the history limit with
hs.console.maxOutputHistory(0)so it could be related to the characters being deleted on #3400.The text was updated successfully, but these errors were encountered: