P2D?::High CPU usage

Issue #148 resolved
Former user created an issue

I'm having some trouble with MacHg using a lot of CPU.

I don't know exactly what is causing this, but after a while with MacHg open it begins using a lot of CPU (80% to 100%). Usually I'm not even using MacHG at the moment it begins, I have it minimized and I'm working on textwrangler with some code.

I'm on Snow Leopard 10.6.5

I hope you can take a look at this issue.

Thanks

Comments (18)

  1. Guido

    Sorry, I'm the one who started this bug, but I wasn't logged in. Should I repost this?

    What do you mean by "a sample"? how can I do this?

  2. Jason Harris repo owner

    Actually it probably doesn't matter if you repost this now... No big deal. Its just nicer for me to have a poster though so I can track who asks what... At least I know who asked the question now. Thanks.

    To get a sample open /Applications/Utilities/ActivityMonitory on your machine. Then click on the sample button as in the following attached graphic.

    The samples would be helpful.

    Thanks, Jas

  3. Anonymous

    I also have this problem with 0.9.12, on latest Snow Leopard. It's sucking up 100% of 4 cores on an i7. Issue happens pretty much randomly and not that often (I've had the issue 3-5 times and MacHG is pretty much always running on my dev box).

    I didn't think of dumping a sample, will certainly do next time it happens and post it here.

  4. Jason Harris repo owner

    Thanks!

    I have actually seen this once myself. The unfortunate thing was in looking at it I accidentally managed to kill the process myself before I got gdb attached to it (I was playing with a standalone release build not a debug one...)

    I tried really hard but I couldn't reproduce it again.

    Thus I believe the reports. Its just I can't track it down yet. If I can get samples from people who see this it would be great!

    On the flip side you can simply quit MacHg and start it again and the problem disappears... Not ideal but since you have very little state in MacHg its not that onerous.

    Thanks for the additional comments!

    Cheers, Jas

  5. Olivier Larivain

    Just had the issue this morning. I made three samples, just in case, they should be roughly the same I guess.

    A little bit of background on what I was doing at that time: - I use almost exclusively the perfarce extension: I have a local repo on my box and I push to the company's Perforce repo fairly often. I'm not sure how relevant that is since it's somehow external to MacHG

    - I had just done a pull from p4 and update the local repo to the tip.

    - Then through eclipse, I synchronized my SCM status (even though I have the hg eclipse plugin, I'd rather use the cool MacHG to do any operation on the repo).

    A couple of seconds after eclipse was done, I heard the fans going crazy and cpu was 100% on all 4 cores.

    I agree it's not critical, since just restarting the app will resolve the issue. It could potentially be an issue if you're away from the laptop and it's on battery, as the fans are going to suck it dry, but it's definitely not the most common use case :)

  6. Alban Leroux

    Hello I have same problem, yesterday 100% CPU usage on osx 10.6.6 and macHg 0.9.13. I observe an intensive refresh rate on the history view. It's blinking at very hight speed (2 or 3 blink per second), can't scroll on etc... This is certainly related. The 100% usage start after 30 seconds after the program is launch (after the first time I use the history view).

    Today nothing. All is normal perhaps this happen after add a repo.

    PS: I started use macHg yesterday.

  7. Jason Harris repo owner

    Ahhh... Steps to reproduce:

    1. Get some repository you are working on and clone it in your MacHg document. You should have at least two local repositories in the one document now.
    2. Restart MacHg and open this document (just to be on the safe side)
    3. Select one of these repositories and go to the browser then the history view
    4. In the MacHg repository sidebar: delete the repository from the document and when queried also delete the underlying repository on the disk.
    5. Once MacHg switches back to the splash screen select the other repository and go to its history view.
    6. This second repository should now be flickering.

    What was happening is that the old RepositoryData was still in existence even though the document didn't point to it, and when a kUnderlyingRepositoryChanged was generally posted this limbo RepositoryData was still trying to update itself. But while the limbo Repository data was trying to update itself it had problems during the update since the repository no longer existed on disk, so it asked for another update which again triggered the limbo repository to ask for an update, etc.

    Meanwhile the good repository that the document actually pointed to was also observing these repeated requests to keep updating and so it flickered as lots and lots of updates took place... It also wound the CPU right up.

    Now... There might be other circumstances which lead to the same behavior, but I can stop this general problem here. I'll post a fix shortly.

    Thanks to everyone who has helped me in posting samples, user reports and stuff. Finally, it was in investigating #179 that I found these steps. But its great to get reports since invariably one will lead to some clue to finally figure out the problem. So thanks again all!!!

    Cheers, Jas

  8. Olivier Larivain

    There definitely are other circumstances where this happens, since I didn't delete a repo in a long time and experience this issue every now and then.

    Anyway, if you found the culprit and fixed it, it doesn't really matter if other use cases trigger the cpu craziness.

    Thanks for the quick resolution!

  9. Mathias Nielsen

    Just happened for me as well. Opened MacHG for the first time and cloned a repo from BB. That all I did so not much help there. I could not scroll down the list of changesets as it kept jumping up to the top. And all cores where running 100%. Didn't think to get a sample sorry. Will repost if I get one. Funny thing is, if I clicked on any menu for MacHG. Inside the window or on the top bar, the CPU usage would drop to 0,7%, but as soon as I closed the menu again, it would go back up.

    Weird :)

  10. Jason Harris repo owner

    - Fix issue 148. We need to abandon and cut off the repository data when we switch the view to the backing view. - What was happening is that the old RepositoryData was still in existence and listening to notifications even though the document didn't point to it. Thus, when a kUnderlyingRepositoryChanged was generally posted this limbo RepositoryData was still trying to update itself. But while the limbo Repository data was trying to update itself it had problems during the update since the repository no longer existed on disk, so it asked for another update which again triggered the limbo repository to ask for an update, etc. Meanwhile the good repository that the document actually pointed to was also observing these repeated notifications to keep updating and so it flickered as lots and lots of updates took place... All of this wound the CPU right up. - Thus I think this accounts for the flicking and high CPU usage. - It also Fixes #158, Fixes #164, Fixes #173, Fixes #178, and Addresses #179.

    861c15c213bc

  11. Log in to comment