30% CPU load with no VM running

[FoxtrotIndia]

I am running into a strange problem with Fusion 3.0.1 on the latest Snow Leopard.

Sometime Fusion, with all its virtual machines suspended, starts, after a while, running at 50% CPU load. After opening and closing the preferences panel of Fusion, the load dropped to 30%. Any idea what might be causing this?

(process samples for both situation are attached)

[rcardona2k]

This is a known bug attributed to an Apple bug in OS X . The issue goes away by quitting and restarting Fusion. In the months I've had Fusion running 24x7, I've run into this 2 times. Not sure what triggers it.

[raznick]

It was claimed to be an OS X bug, but there were never any real details provided that prove it beyond a single random posting related to a Norton product. I had hoped to hear back about whether anything was submitted to Apple or if there was any further confirmation about the cause of the problem. Unfortunately, I have heard nothing. It's a really frustrating bug.

[raznick]

Oh, and I'll just add that I run into it every single day.

[Alfazone]

I have tested it with leopard 10.5.8 and the same happens there as well. It's easy to reproduce the bug, I can just hit check for updates in the fusion menu about 10-15 times and then I can sit and see that cpu and memory usage of the fusion ui grows. This also happens if you don't have any vm and on a reinstalled clean snow leopard and leopard with the only thing installed vmware fusion. It never happened to me with vmware fusion 2.x

[FoxtrotIndia]

This is interesting. With my installation as well, when I do a few manual check updates in quick succesion, the CPU load starts to grow, and continues to grow afterwards. I did two test, one with about 20 checks, then the cpu load rose to 100% pretty quickly, and one with 5 checks, then the cpu load rose much slower, after a few minutes it was at 17%, finally rising to over 50%.

Strangely I had the impression that if I did only one update check, the cpu load would not rise, staying constant at 0.1%. A second update check 4 minutes later raised the load to 0.9%, and it keeps rising from then on, after a good 5 minutes it is at 1.5%. I will let it run a bit to see where it stops (100%?).

In all of this I have started Fusion, it loaded the windows of a few suspended VMs, and I did not start any VMs, I just invoked the check for updates command with the mouse. I had automatic update checking disabled. Given how repeatable this problem is, I hope VMWare will soon be able to fix this annoying issue.

Maybe one should disable automatic update checking in the hope that this will prevent VMWare from triggering this bug.

[rcardona2k]

Check for updates is a good reproduction case! Worked for me getting my CPU to climb from < 1, by 1% until about 15% then big steps past 30%, then level off to 100%. Interestingly, the load switched between cores from sample to sample with nothing else running except Fusion and Activity Monitor.

The implicator in the Activity Monitor samples is the call to -[NSProgressIndicator _animationIdler:]. Which implies avoiding the native Cocoa progress indicator. Fusion 3 uses it's own progress for suspend/resume which may be a way of avoiding NSProgressIndicator.

My usage pattern is that i don't quit Fusion, ever. I do have "check for updates" checked but I never invoke it manually (which brings up the UI and progress bar.) My idle CPU for the Fusion UI is < 1%.

Do you have other use cases which bring up the native OS progress bar or barber pole indicators in Fusion?

[FoxtrotIndia]

I have now let this test run for while (Invoked Check for Updates twice on a freshly started Fusion instance, without any VMs running), I have now points at 2.8% utililisation, 9.0% an hour later and 30% another hour later, with it stabilising at around 50% to 60% in the end. Process samples at several points are attached.

What I find interesting is that VMWare seems to consume more and more time sorting (CFQSortArray) as time passes, as if it is filling a list, but not removing items from it once done with them.