Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memory Leak? #85

Closed
xluk9 opened this issue Jul 1, 2018 · 5 comments
Closed

Memory Leak? #85

xluk9 opened this issue Jul 1, 2018 · 5 comments
Labels
BUG 八哥

Comments

@xluk9
Copy link

xluk9 commented Jul 1, 2018

  • 问题描述 | Issue description:
    I guess there is a memory leak issue. I leave my macbook in standby most of the time, in particular at night. So, I turn off completely the external mouse. After a weak of usage, I saw in the Activity Monitor that Mos used 297MB of memory, which is quite a lot. I forgot to make a screenshot before closing and reopening the app.

  • 如何重现 | How to reproduce it:
    Normal daily usage, no gaming and no heavy scrolling. Even when you don't use the mouse or the scroll, you can see the memory usage increases.

  • 软件版本 | Application version:
    2.2.6

  • 系统版本 | System version:
    macOS 10.13.4

  • 您系统中的其他鼠标管理软件 | Other mouse management application in your system:
    Nothing, the default system settings.

You can find a little test I did for 2 days, where the night the mouse and macbook are not used at all.
Imgurl screeshots of 2 days

Btw great app!

@Caldis
Copy link
Owner

Caldis commented Jul 2, 2018

@Kandiu Thanks for your feed back !

In fact, i already notice the memory leak in daily usage. But the difficulty is that the memory leak problem is very difficult to locate. According to my long experience of using Mos, the memory usage will not continue to grow at around 300MB. So this problem will not affect the daily usage, if you think this problem has However, you can only manually restart the application.

I will try to fix this problem in future. If you have more information to provide, please continue to feedback.

@Caldis Caldis added the ENHANCEMENT 改进 label Jul 2, 2018
@xluk9
Copy link
Author

xluk9 commented Jul 6, 2018

I was looking at the source code. I've never wrote anything in Swift nor Objective C. I don't actually understand all the source code of Mos.

I see that you never release the event reference in method scroll in file MouseEvent.m. Now, I have no idea how the Apple ecosystem works at all, but going through the documentation it is mentioned that we should free the the object created by CGEventCreateScrollWheelEvent with CFRelease.
I added the CFRelease(event) after CGEventPost...... I'm testing for a couple of hours, it seems quite stable the memory usage. In fact it started at 6.9MB and, after 6hrs of usage, it went to 7.8MB and it stays there.

The thing I noticed is that it increases each time I login after a lock screen. This doesn't happen if you lock screen and login immediately after., but if you give some time, like 1hr between a lock screen and a log in, you will see the increase in memory.

I hope this gives some more insight on the problem.

@Caldis
Copy link
Owner

Caldis commented Jul 7, 2018

@Kandiu Deeply thanks for your support !

The code your fixed indeed is an unreleased object and i always thought that the object which is created by CGEventCreateScrollWheelEvent was under ARC's control. But when i checked the document again and i found the object does need to be manually released.

I also found another leak point on Unmanaged.passRetained(event) will cause the returned 'event' not to be properly released.

@Caldis Caldis added BUG 八哥 and removed ENHANCEMENT 改进 labels Jul 8, 2018
@wyudong
Copy link

wyudong commented Jul 11, 2018

I've never wrote anything in Swift nor Objective C. I don't actually understand all the source code of Mos.

I see that you never release the event reference in method scroll in file MouseEvent.m……

How do you locate the leak even though you don't know Swift or Objective-C? What's your magic :)

@Caldis
Copy link
Owner

Caldis commented Jul 13, 2018

@wyudong HaHaHa but he really did it.
@Kandiu Try 2.3.0

@Caldis Caldis closed this as completed Oct 24, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
BUG 八哥
Projects
None yet
Development

No branches or pull requests

3 participants