[GH-ISSUE #1087] Possible memory leak in arm64ddc? #645

New issue

Closed

opened 2026-05-05 06:26:15 -06:00 by gitea-mirror · 2 comments

gitea-mirror commented

2026-05-05 06:26:15 -06:00

Owner

Originally created by @krackers on GitHub (Jun 16, 2022).
Original GitHub issue: https://github.com/MonitorControl/MonitorControl/issues/1087

Originally assigned to: @krackers on GitHub.

Before opening the issue, have you...?

Searched for existing issues
Looked through the wiki
Updated MonitorControl to the latest version (if applicable)

Describe the bug

In this file https://github.com/MonitorControl/MonitorControl/blob/main/MonitorControl/Support/Arm64DDC.swift (and possibly the intel version), I don't see any CFRelease/IOObjectRelease calls, despite the fact that the docs say you must release the iterator and any objects as you iterate through them. But I'm not 100% familiar with swift, does it wrap iokit to take care of these things for you?

Also you should consider using CFSTR macro instead of CFStringCreateWithCString for the string constants that are fixed, so that way you avoid any runtime allocation entirely

Note that I have not traced through instruments to see how big of an impact this is

Steps to reproduce

Read through code
Notice no cfrelease/ioobject release calls

Expected behavior

cfrelease/ioobjectrelease calls added as appropriate

Anything else?

No response

Environment Information (please complete the following information)

- macOS Version 12.4
- MacBook Pro (16-inch, 2021
- Apple Silicon: Yes
- Monitor Control versions: Should affect anything that supports m1?

Originally created by @krackers on GitHub (Jun 16, 2022). Original GitHub issue: https://github.com/MonitorControl/MonitorControl/issues/1087 Originally assigned to: @krackers on GitHub. ### Before opening the issue, have you...? - [X] Searched for existing issues - [X] Looked through [the wiki](https://github.com/MonitorControl/MonitorControl/wiki) - [X] Updated MonitorControl to the latest version (if applicable) ### Describe the bug In this file https://github.com/MonitorControl/MonitorControl/blob/main/MonitorControl/Support/Arm64DDC.swift (and possibly the intel version), I don't see any `CFRelease`/`IOObjectRelease` calls, despite the fact that the docs say you must release the iterator and any objects as you iterate through them. But I'm not 100% familiar with swift, does it wrap iokit to take care of these things for you? Also you should consider using `CFSTR` macro instead of `CFStringCreateWithCString` for the string constants that are fixed, so that way you avoid any runtime allocation entirely Note that I have not traced through instruments to see how big of an impact this is ### Steps to reproduce * Read through code * Notice no cfrelease/ioobject release calls ### Expected behavior * cfrelease/ioobjectrelease calls added as appropriate ### Anything else? _No response_ ### Environment Information (please complete the following information) ```markdown - macOS Version 12.4 - MacBook Pro (16-inch, 2021 - Apple Silicon: Yes - Monitor Control versions: Should affect anything that supports m1? ```

gitea-mirror

2026-05-05 06:26:15 -06:00

closed this issue
added the
done
label

gitea-mirror commented

2026-05-05 06:26:20 -06:00

Author

Owner

@waydabber commented on GitHub (Jun 16, 2022):

HI @krackers - yes, all objects returned by IOKitLib should be released with this function when access to them is no longer needed.. I did not see any practical downside of skipping this in Arm64DDC even while running the app for prolonged time (the effect seems to be minimal), but still, it is proper to call IOObjectRelease on the iterators as advised. I don't think there is any special swift related mechanism is in place to do this with IOKit objects, so it's just an omission on my part (sorry about that). Thanks for pointing it out!

IntelDDC does this better, but that is thanks to @reitermarkus, not me, I just took most of his code and repurposed it for MonitorControl.

Please, feel free to contribute to the code or fix/improve whatever you feel must be improved! :)

@waydabber commented on GitHub (Jun 16, 2022): HI @krackers - yes, `all objects returned by IOKitLib should be released with this function when access to them is no longer needed.`. I did not see any practical downside of skipping this in Arm64DDC even while running the app for prolonged time (the effect seems to be minimal), but still, it is proper to call IOObjectRelease on the iterators as [advised](https://developer.apple.com/documentation/iokit/1514627-ioobjectrelease). I don't think there is any special swift related mechanism is in place to do this with IOKit objects, so it's just an omission on my part (sorry about that). Thanks for pointing it out! IntelDDC does this better, but that is thanks to @reitermarkus, not me, I just took most of his code and repurposed it for MonitorControl. Please, feel free to contribute to the code or fix/improve whatever you feel must be improved! :)

gitea-mirror commented

2026-05-05 06:26:21 -06:00

Author

Owner

@waydabber commented on GitHub (Sep 18, 2022):

Made the proposed changes: https://github.com/MonitorControl/MonitorControl/pull/1181

@waydabber commented on GitHub (Sep 18, 2022): Made the proposed changes: https://github.com/MonitorControl/MonitorControl/pull/1181

gitea-mirror referenced this issue

2026-05-05 07:06:02 -06:00

[PR #645] [MERGED] feat: close preference pane using cmd + w #1146