GP SoftwareTwitter
Opus FAQsManualCommandsObjects

High memory and CPU usage during VS2010 unit tests


#1

I have a very odd problem going on here. Opus is saturating one of my CPU cores and chewing through memory at a rate of knots - currently around 14GB and climbing - and is completely unresponsive. The only way to regain control is to kill it off using the Task Manager.

This happens pretty much every time I run unit-tests in VisualStudio 2010. I cannot see the link, but I have not seen this behaviour from Opus prior to starting to write these tests a few weeks ago, and I haven't yet seen anything else trigger it.

I have no plugins installed in Opus - it's a clean OOTB installation - and no shell-extensions of which I am aware that could cause this.

Has anyone seen anything like this before?


#2

Do you have some anti virus installed by any chance?


#3

Oh, sorry, i overlooked your comment about VisualStudio. There is a FAQ on this forum desribing how to hunt down issues like that using
ProcessMonitor, i think. Or Sysinternal´s Process Explorer also might be helpful for some in depth check of which thread is causing the problem.


#4

If you set Preferences / Miscellaneous / Advanced: no_external_change_notify to True, does the CPU and memory usage go back to normal?

(If not, does it do so if you fully exit Opus and then restart it?)


#5

Opus is unresponsive - it can only be killed via the Task Manager. After restarting it, things are back to normal - at least until the next time it happens.

I'll try changing that setting and report back.


#6

Nope, no difference.

The memory usage seems to be topping out at around the 14GB mark, possibly because - once you factor in the memory being used by other processes - that's when it's reached the amount of physical RAM in the system.


#7

Does that happen even if you close all Opus windows but one, and in that window you navigate to an empty folder and turn off the folder tree?

If you're familiar with Process Explorer then it may be worth using that to see which exe or dll contains the code that is using the CPU. (Ignore the reported function names, though; they are usually red.) It could be Opus itself or a system component, but it may also be a shell extension or similar.


#8

I typically only have the one Opus window open, in dual-lister mode with dual folder-trees. I'll try changing the settings around and see what happens.


#9

No, no change - with a single basic Opus lister pointing at an empty folder, I've just had the same problem.

This may simply be that I haven't seen it yet, but: so far I only seem to get one of these per session. That is, after killing and restarting Opus as described above, I then don't encounter the problem again until after the next reboot. Probably just coincidence, but I'll keep checking.


#10

Do you have any source control shell extensions (SVN, Git, etc.) installed that might be reacting to changes that Visual Studio is making? They could be a factor.


#11

Yes, I have TortoiseSVN installed. I'd have thought if it were the culprit then I'd also see this problem simply by editing files, but I shall investigate further.


#12

Just happened again. dopus.exe is pummeling the CPU, and its stack frame currently looks like this:

ntoskrnl.exe!KeWaitForMultipleObjects+0xc0a
ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x732
ntoskrnl.exe!KeWaitForSingleObject+0x19f
ntoskrnl.exe!_misaligned_access+0xba4
ntoskrnl.exe!_misaligned_access+0x1821
dopuslib.dll!DoesExeFileContainZip+0x63a5a
dopuslib.dll!DoesExeFileContainZip+0x63ae3
dopuslib.dll!DoesExeFileContainZip+0x5d1f7
dopuslib.dll!DoesExeFileContainZip+0x5fc69
dopuslib.dll!stricmpnW+0x3b
dopus.exe+0x1581b
dopus.exe!RevertWow64Redirection+0x1363d4
dopus.exe!RevertWow64Redirection+0x13567c
dopus.exe!RevertWow64Redirection+0x1386e9
USER32.dll!GetWindowDC+0x81
USER32.dll!SetWindowTextW+0x277
USER32.dll!RegisterPowerSettingNotification+0x13c
ntdll.dll!KiUserCallbackDispatcher+0x1f
USER32.dll!SfmDxSetSwapChainStats+0x1a
USER32.dll!GetMessageW+0x2a
dopus.exe!RevertWow64Redirection+0x1400de
dopus.exe!RevertWow64Redirection+0x13cb01
dopus.exe!RevertWow64Redirection+0x13c16c
dopus.exe!OPENSSL_Applink+0x22239f
kernel32.dll!BaseThreadInitThunk+0xd
ntdll.dll!RtlUserThreadStart+0x21


#13

Under advanced prefs again, if you turn on all three of these:

[ul][li]no_external_change_notify (as before)[/li]
[li]notify_debug[/li]
[li]shellchange_debug[/li][/ul]

Then run DebugView, do you see output about changes below the folders VS2010 is working in?

(There may also be some, or even a lot, of output from other programs in there as some programs are very "chatty" with their debug output even if it isn't explicitly enabled. If you reset the latter two settings it should turn off all debug output coming from Opus to let you compare against how things normally look on your system.)


#14

Ok...absolutely nothing from dopus whilst the tests are running.


#15

If you turn no_external_change_notify off again, do you start to see things in DebugView?


#16

Yes - there are numerous changes to files in subfolders of my VS project folder. I can't see anything for the immediate contents of that folder, which is the one I have open in Opus.


#17

Could you post a screenshot of your Opus setup, making all the file display columns visible if possible.

BTW, did you try with the folder tree turned off before, or was it still on when you had just one window pointing at an empty dir?


#18

All tests done today were with Opus looking roughly as it does in the screenshot. I haven't tried the 'minimal' approach again since last night.



#19

Did you ever try with the folder trees turned off?

Presumably the unit tests & related files are all on the local drive(s), not the network drives?


#20

Yes, last night. I had a single-view lister pointing at an empty folder. The problem still occurred.

Yup, everything is in the folder shown on the left, which is a local harddrive.