Closed fiwswe closed 1 year ago
Issue located and fixed, thank you. Will be available in the upcoming update (1.5.1)
Wow, that was fast. Thanks!
I'll let you know the results when the new version is out.
Thanks for letting me test this!
I have rebooted the Mac mini, quit the older (1.5.0.1) app, replaced it with the 1.5.1.2 (beta) app, launched the beta and…
A few seconds after launch (after closing the main window) [2019.10.01 13:13:50]: com.crystalidea.macsfancontrol.smcwrite: 668 KB, the app: 37.5 MB. Mach ports: 27, 241 respectively.
About 59 min. later [2019.10.01 14:12:50]: com.crystalidea.macsfancontrol.smcwrite: 652 KB, the app: 53,2 MB. Mach ports: 25, 253 respectively.
During this time I watched the memory for the app slowly climb up. I did not interact with MFC at all during this time and mostly left the machine running without any interaction.
Neither the MFC settings nor anything else on the machine was (manually) modified since the original bug report.
Conclusion:
Here are screen shots of Activity Monitor to illustrate the issue: [2019.10.01 13:13:50]
[2019.10.01 14:12:50]
And this is what the menu bar display is configured to be (in case that makes any difference):
I can confirm that, found only one memory leak, seem like there's another one. Will keep searching, thank you
Can you please try the 1.5.1 beta?
Ok, I have started the test. I'll let you know shortly what the results are…
Alright, it seems you are on the right track! The leak is getting smaller.
Setup: I am running the 1.5.1.5 (beta, Sierra) version as my Mac mini uses macOS 10.12.6. Again nothing was changed manually on the machine from previous tests except for replacing MFC.
Results: Here are the numbers (only for the app memory as all the other values seem normal):
For reference: The previously tested version 1.5.1.2 (beta) had leaked an average of 4.54 KB/s for a total of 15.7 MB after 59 min.. This went down to an average of 3.08 KB/s over 02:06:56:24 days for a total of 595.0 MB.
@fiwswe thank you very much for the feedback!
Update: After a runtime of 02:06:07:26 days the leak grew to 274.3 MB (ø1.44 KB/s).
That is considerably less than version 1.5.1.2 (beta) which leaked 595 MB (ø3.08 KB/s) after the comparable time of 02:06:56:24 days.
Please try the latest beta https://github.com/crystalidea/macs-fan-control/issues/218
Hi!
Same resting environment as before, only with the new version 1.5.1.5 beta, Sierra, you made available today:
• Very shortly after launch (after closing the main window): 36.1 MB • ∆T: 01:22:00: 47.6 MB (ø leaks 2.39 KB/s for a total of 11.5 MB)
So while not perfect yet it looks like an ≈38% improvement on the memory leak issue. I'll keep it running and report more data later…
Thanks!
BTW: Not sure if this is an issue or not, but when quitting the app (using the menu command) the helper tool keeps running. I used Activity Monitor to quit the helper tool before running the new version.
Thank you, will keep searching.
Not sure if this is an issue or not, but when quitting the app (using the menu command) the helper tool keeps running.
It's totally normal.
Here is the promised update: • ∆T: 00:17:31:41: 174.9 MB (ø leaks 2.25 KB/s for a total of 138.8 MB) • ∆T: 02:11:59:46: 253.8 MB (ø leaks 1.03 KB/s for a total of 217.7 MB)
I have started testing version 1.5.1.6 (sierra) today. Here are the first results:
• Very shortly after launch (after closing the main window): 36.3 MB • ∆T: 17:26:07: 179.6 MB (ø leaks 2.34 KB/s for a total of 143.3 MB)
This value seems to be slightly worse than the corresponding value from version 1.5.1.5 (beta, sierra dated Nov. 5th.). Although the difference is small enough to be considered a natural fluctuation.
Update: • ∆T: 00:23:33:23: 235.9 MB (ø leaks 2.41 KB/s for a total of 199.6 MB) • ∆T: 05:09:45:53: 861.1 MB (ø leaks 1.81 KB/s for a total of 824.8 MB)
Thank you for the follow up, will keep digging!
Final update for version 1.5.1.6 (sierra): • ∆T: 09:09:45:40: 887.0 MB (ø leaks 1.07 KB/s for a total of 850.7 MB) • ∆T: 11:14:25:08: 895.6 MB (ø leaks 0.88 KB/s for a total of 859.3 MB) • ∆T: 29:20:55:23: 2,220 MB (ø leaks 0.87 KB/s for a total of 2,183.7 MB)
So clearly the average rate of the leaks goes down over time but given very long runtimes the accumulated leaks are still significant.
I have downloaded and installed version 1.5.3.9 and started testing:
• Very shortly after launch (after closing the main window): 36.9 MB • ∆T: 00:27:28: 39.0 MB (ø leaks 1.28 KB/s for a total of 2.1 MB, lowest value for this runtime yet!) • ∆T: 01:21:20: 43.4 MB (ø leaks 1.36 KB/s for a total of 6.5 MB, lowest value for this runtime yet!) • ∆T: 02:44:21: 44.9 MB (ø leaks 0.83 KB/s for a total of 8.0 MB, lowest average value yet!)
Good work! Things seem to be improving on the memory leak front :-)
Thanks a lot for the follow up.
still leaking. version 1.5.7.20 is using 143MB and the leaks
commands reports 1041271 leaks for 99961088 total leaked bytes
.
Hadn’t noticed this before. Macs Fan Control 1.5.8.21 Pro (iMac19,1).
Physical footprint: 1.1G
Physical footprint (peak): 1.1G
----
leaks Report Version: 4.0
Process 532: 14239605 nodes malloced for 1088844 KB
Process 532: 14100443 leaks for 1092767760 total leaked bytes.
Just wonder what language is the app coded in, I understand memory leaks in the kernel since it's written in c and assembler.
I do need to know which settings are used. Sensor-based control? A screenshot of the app would be fine. Thanks.
At the time I was experiencing this issue, I was switching between the following two profiles:
These days, I stick to a single one, and I also have a scheduled job that automatically restarts Macs Fan Control, so I haven’t observed it. I will disable it and report back if I experience memory leaks using a single profile.
Please post the complete output of the leaks command (when you experience leaks). Thanks!
Sorry it’s taken so long. I’ve rebooted my computer more frequently lately, and Macs Fan Control wasn’t leaking memory even after several days. Weirdly enough, leaks has been reporting no leaks even when the app was taking 800+ MiB of memory at times. This time, it’s only sitting on 117 MiB.
omg, thanks a lot, we found the leak! Will be fixing it asap
Quick build with NSMutableParagraphStyle leak fixed.
Thanks a bunch! Will keep an eye on it.
it seems like memory leaks are still happening
Process 66937 is not debuggable. Due to security restrictions, leaks can only show or save contents of readonly memory of restricted processes.
Process: Macs Fan Control [66937] Path: /Applications/Macs Fan Control.app/Contents/MacOS/Macs Fan Control Load Address: 0x102638000 Identifier: com.crystalidea.macsfancontrol Version: 1.5.12 (41) Code Type: ARM64 Platform: macOS Parent Process: ??? [1]
Date/Time: 2022-05-26 08:23:12.349 -0400 Launch Time: 2022-05-22 15:44:42.627 -0400 OS Version: macOS 12.3 (21E230) Report Version: 7 Analysis Tool: /usr/bin/leaks
Physical footprint: 258.0M Physical footprint (peak): 258.4M
leaks Report Version: 4.0 Process 66937: 2597863 nodes malloced for 191092 KB Process 66937: 2518877 leaks for 181375264 total leaked bytes.
the rest of the logs are too big, so here's a snippet
1 (16 bytes) ROOT LEAK: 0x600002539470 [16] 1 (16 bytes) ROOT LEAK: 0x600002539480 [16] 1 (16 bytes) ROOT LEAK: 0x600002539490 [16] 1 (16 bytes) ROOT LEAK: 0x6000025394a0 [16] 1 (16 bytes) ROOT LEAK: 0x6000025394b0 [16] 1 (16 bytes) ROOT LEAK: 0x6000025394c0 [16] 1 (16 bytes) ROOT LEAK: 0x6000025394f0 [16] 1 (16 bytes) ROOT LEAK: 0x600002539540 [16] 1 (16 bytes) ROOT LEAK: 0x600002539550 [16] 1 (16 bytes) ROOT LEAK: <QCocoaSegmentedButtonTarget 0x600002530a40> [16]
sometimes after a few days, it can reach around 600MB
please upload complete logs somewhere.
While the leaks have decreased, thanks @kleuter, I have given up on getting them all fixed. I use this, launched once a day via user crontab:
#!/bin/bash
#
# As a workaround for memory leaks in Macs Fan Control we restart the app on a schedule.
#
MFC_PROCESSNAME='Macs Fan Control'
# NOTE: Modify the path if you put the app somwehre else:
MFC_APP='/Applications/Macs Fan Control.app'
/usr/bin/killall -u "$(/usr/bin/whoami)" -HUP "$MFC_PROCESSNAME"
if [ $? -eq 0 ];then
/usr/bin/open "$MFC_APP"
fi
#
# EOF.
#
(MFC 1.5.11 running on macOS 10.12.6 on an old 2010 Mac mini Server with a broken HD temp sensor connector, which can not be upgraded to a more modern OS.)
HTH fiwswe
Just rebooted MFC 1.5.15 for just this, was using nearly 1GB RAM; restarted it's <100MB
Please post the complete output of the leaks command in Terminal (when you experience leaks). Thanks!
$ leaks 500
Process 500 is not debuggable. Due to security restrictions, leaks can only show or save contents of readonly memory of restricted processes.
Process: Macs Fan Control [500]
Path: /Applications/Macs Fan Control.app/Contents/MacOS/Macs Fan Control
Load Address: 0x102a10000
Identifier: com.crystalidea.macsfancontrol
Version: 1.5.15 (55)
Code Type: ARM64
Platform: macOS
Parent Process: ??? [1]
Date/Time: 2023-05-12 21:51:54.597 +0100
Launch Time: 2023-05-07 09:37:30.103 +0100
OS Version: macOS 13.3.1 (22E261)
Report Version: 7
Analysis Tool: /usr/bin/leaks
Physical footprint: 338.9M
Physical footprint (peak): 339.1M
Idle exit: untracked
----
leaks Report Version: 4.0
Process 500: 4476542 nodes malloced for 320638 KB
Process 500: 4424715 leaks for 318577936 total leaked bytes.
After terminating the process, I got a lot of output in my terminal
Macs Fan Control (MFC) is running for days and weeks at a time on my Mac mini server. I have noticed that it tends to accumulate a lot of memory over time. Quitting MFC and restarting it will restart the cycle.
The issue has existed with older versions of MFC as well. I had hoped that issue #185 would have fixed the memory problem. But while the number of Mach ports now seems stable, the memory leak persists.
For example: After launch of MFC: com.crystalidea.macsfancontrol.smcwrite: 644 KB, the app: 38.8 MB. An hour later: com.crystalidea.macsfancontrol.smcwrite: 644 KB, the app: 50.5 MB. About 67:30 hours after launch: com.crystalidea.macsfancontrol.smcwrite: 688 KB, the app: 1,010.1 MB.
During this time the configuration window was only open at the beginning (at most an hour or so). After that the machine was running without user interaction.
FWIW: I have not enabled fan related activities in iStat Menus so hopefully there should be no conflict.