You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hey, it's so hard to find a repro steps for this issue but it happens ~once per hour. Dimble just crashes/closes in random moments (yes, Dimble.app process is not visible in Activity Monitor). For instance, Today it stopped working at 13:17 -> unfortunately there are no logs related to this crash in the attached log file.
Btw: the issue persisted on every previous builds I've tested before... I finally decided to report it. :)
Hey @cookie-drummer, your log does have the moment. The last line is 13:13:24.561, a routine background walk, then nothing until Dimble starts again at 13:18:52. Nothing odd in the seconds before it goes quiet.
The reason you found nothing is partly on me. The first 355 KB of the file you attached is zeros, so the earlier part of that session got wiped when the log rotated. Dimble doesn't log its own quit either, so right now the log can't tell a crash from something killing it. I'll add that line so the next one says which.
Counting the restarts, Dimble went down 21 times over the days your log covers, a few of them seconds apart.
Two things would narrow it down next time it happens:
1- Look in ~/Library/Logs/DiagnosticReports for a file starting with "Dimble" that ends in .ips. If there's none, something killed it rather than it crashing on its own.
2- Run this in Terminal right after and attach the file:
Hey, that one caught the death but not what caused it. Dimble's pid 75167 goes at 23:44:31, and the lines around it are only the system noticing, WindowServer then WindowManager then loginwindow. No crash report was written in that half hour either.
The predicate I gave you is the problem. Dimble's bundle id is still app.fif7y.Pelmet, so whatever killed it names that, or just the pid. My filter only matched the word "Dimble".
Two things:
1- Did you get to look in ~/Library/Logs/DiagnosticReports for a file starting with "Dimble" that ends in .ips? That answers it on its own. Nothing there means something killed it rather than it crashing.
2- Next time it happens, this one instead:
/usr/bin/log show --last 30m --predicate 'eventMessage CONTAINS "Pelmet" OR eventMessage CONTAINS "Dimble" OR process == "ReportCrash" OR (process == "launchd" AND eventMessage CONTAINS "kill")' --style compact > ~/Desktop/dimble-kill2.txt
It's also worth moving off beta.6 to 0.3.4. It logs stop: quitting when Dimble quits on purpose, and it doesn't wipe the earlier part of the log when the file rotates anymore. A log that just stops with no stop: line then tells us it didn't quit.
Hey @cookie-drummer, thanks! No .ips means something killed it rather than a crash.
Next time, attach ~/Library/Logs/Dimble/dimble.log along with dimble-kill2.txt. 0.4.0 writes stop: quitting on a normal quit, so the two together should tell us what did it.
Activity
fif7y commentedon Nov 6, 2026
Hey @cookie-drummer, your log does have the moment. The last line is 13:13:24.561, a routine background walk, then nothing until Dimble starts again at 13:18:52. Nothing odd in the seconds before it goes quiet.
The reason you found nothing is partly on me. The first 355 KB of the file you attached is zeros, so the earlier part of that session got wiped when the log rotated. Dimble doesn't log its own quit either, so right now the log can't tell a crash from something killing it. I'll add that line so the next one says which.
Counting the restarts, Dimble went down 21 times over the days your log covers, a few of them seconds apart.
Two things would narrow it down next time it happens:
1- Look in ~/Library/Logs/DiagnosticReports for a file starting with "Dimble" that ends in .ips. If there's none, something killed it rather than it crashing on its own.
2- Run this in Terminal right after and attach the file:
The log keeps the lines it already had, and says when Dimble quits (#130
cookie-drummer commentedon Nov 7, 2026
I have finally caught the moment. File attached. :)
dimble-kill.txt
fif7y commentedon Nov 8, 2026
Hey, that one caught the death but not what caused it. Dimble's pid 75167 goes at 23:44:31, and the lines around it are only the system noticing, WindowServer then WindowManager then loginwindow. No crash report was written in that half hour either.
The predicate I gave you is the problem. Dimble's bundle id is still
app.fif7y.Pelmet, so whatever killed it names that, or just the pid. My filter only matched the word "Dimble".Two things:
1- Did you get to look in ~/Library/Logs/DiagnosticReports for a file starting with "Dimble" that ends in .ips? That answers it on its own. Nothing there means something killed it rather than it crashing.
2- Next time it happens, this one instead:
It's also worth moving off beta.6 to 0.3.4. It logs
stop: quittingwhen Dimble quits on purpose, and it doesn't wipe the earlier part of the log when the file rotates anymore. A log that just stops with nostop:line then tells us it didn't quit.cookie-drummer commentedon Nov 8, 2026
Hey,
1 -> there is nothing starting with "Dimble" that ends in .ips;
2 -> sure, will do that once it happens again.
(already moved to beta 0.4.0)
fif7y commentedon Nov 8, 2026
Hey @cookie-drummer, thanks! No .ips means something killed it rather than a crash.
Next time, attach ~/Library/Logs/Dimble/dimble.log along with dimble-kill2.txt. 0.4.0 writes
stop: quittingon a normal quit, so the two together should tell us what did it.