I have a MacOS app with a memory leak. According to the Leaks.app, there's a problem with NSIdleTimer's setHandler method.
I'm not using that object (which I can't find any documentation on). But I am using:
sleep(1)
as a means of preventing a race condition.
Might that be the cause? Anything I need to do with sleep to deallocate memory?
Or is it an OS bug?
I think we need a bit more information to be able to help here.
I'm not aware of a Leaks.app. Are you using the leaks command line tool or the Leaks instrument in the Instruments application?
Are you able to attach a screenshot of what you are seeing, or maybe a memgraph that captured the leak?
What is the type of the object that's being leaked, and is it leaked by itself or as part of a bigger reference cycle?
Is it something you can easily reproduce in a small example project?
As an aside: Using sleep to avoid a race condition is usually not a good idea. In most cases it only makes the race condition less likely to occur but doesn't actually solve it and it's hard to guess whether it will actually make it less or more likely for your customers.
Instead, look into using concurrency tools like locks, dispatch queues, or Swift Concurrency to prevent the race condition.
Thanks for the reply: the good people of Stack Exchange fixed it (but then told me to delete the question as not being as good fit for the site....)
In short: the way Timer.scheduledTimer is used has changed***. Someone supplied me with a different formula for using it, and that seems to have fixed it.
I removed the sleep, and it seems to not be a problem without it. Anyway, the leak is fixed.
*** What do you want to change things for? Things are bad enough as they are!
