Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error
VS2012 RC split window loses indicators
Options
Previous Topic Next Topic
johnmwright
#1 Posted : Friday, June 22, 2012 3:10:24 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 9/27/2011(UTC)
Posts: 45
Location: Chicago, IL

Thanks: 3 times
Was thanked: 7 time(s) in 6 post(s)
In VS2012 RC, when editing a source file (C# in my case), if you split the window (menubar: Windows -> Split), the top window frame no longer has the ncrunch red/green indicators, while the bottom frame does. If you then remove the window split, the top window survives, thus the file no longer has the indicators. If you close, then reopen the file, the indicators return.


I'm running:
NCrunch 1.40.0.23b
Visual Studio 2012 RC (v11.0.50522.1 RCREL)
ReSharper 7 EAP (Build 7.0.64.89 - from 2012-06-09T03:14:46)


On a side note:
I'm very happy with the 1.40 release. It's very speedy and lighter on memory than previous releases (although I'm still seeing the BuildHost instances take about 900MB each, whereas VS2012 is only using 625MB). Keep up the good work -- this is a great piece of software!
Back to top
Remco
#2 Posted : Monday, June 25, 2012 12:34:10 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,123

Thanks: 957 times
Was thanked: 1286 time(s) in 1193 post(s)
Hi John,

Thanks for reporting this! I'll add it to the list of compatibility issues to check over for VS2012.

I'm curious about the memory utilisation you've described for the BuildHost, as usually I don't see this go over 100MB per process. Do you find this memory utilisation increases rapidly or does it slowly leak up over time?
Back to top
johnmwright
#3 Posted : Monday, June 25, 2012 12:45:59 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 9/27/2011(UTC)
Posts: 45
Location: Chicago, IL

Thanks: 3 times
Was thanked: 7 time(s) in 6 post(s)
The memory issues are slow leaks over time, as best as I can tell. It's not something I monitor that closely, as my dev machine usually has plenty of memory to spare. I did notice later that same day the two BuildHost processes were up to 1.3 GB each. However, they are currently at 200MB each. I don't recall if I restarted VS in that timeframe.

I tried attaching a memory profile to the process once when they were in the 1GB+ range, but during the time it took the profiler to take a memory snapshot, the process died, so I couldn't get a feel for where the memory is going. Initially, I suspected it was something I was doing in my test code around testing static classes/singletons, but after you renamed the processes in a recent release to separate the build from test processes, I noticed it was the BuildHost that was getting big.

I tend to leave VS open overnight and usually notice the memory usage first thing in the morning, but I don't know if that's because it's grown overnight, or if I just wasn't paying attention to memory during the day before.

I'll start taking notes this week tracking memory footprint over time and try to locate any trends.
Back to top
johnmwright
#4 Posted : Tuesday, June 26, 2012 3:42:33 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 9/27/2011(UTC)
Posts: 45
Location: Chicago, IL

Thanks: 3 times
Was thanked: 7 time(s) in 6 post(s)
Re: memory usage.

Just watching the memory usage over the last 24 hours, I've seen it grow from 226KB to 1.3GB. Specific readings below.
What additional information can I collect for you to help determine what's being stored in memory? Would a bug report from within VS provide any snapshot details like that?

Readings via Window7 Task Manager for nCrunch.BuildHost.x86.exe processes :

Mon, 8:05AM
ProcessId WorkingSet PeakWorkingSet
8664 226,680 K 391,332 K
9396 233,180 K 262,056 K


Mon, 11:09AM
ProcessId WorkingSet PeakWorkingSet
8664 449,020 K 472,368 K
9396 449,604 K 455,088 K


Mon, 12:39PM
ProcessId WorkingSet PeakWorkingSet
8664 626,940 K 635,900 K
9396 646,744 K 669,232 K

Mon, 3:00PM
ProcessId WorkingSet PeakWorkingSet
8664 719,324 K 749,164 K
9396 739,128 K 761,708 K

Mon, 5:40PM
ProcessId WorkingSet PeakWorkingSet
8664 1,003,156 K 1,031,340 K
9396 1,010,748 K 1,033,052 K

Tue, 10:29AM
ProcessId WorkingSet PeakWorkingSet
8664 1,293,932 K 1,326,176 K
9396 1,295,996 K 1,325,152 K
Back to top
Remco
#5 Posted : Wednesday, June 27, 2012 9:51:18 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,123

Thanks: 957 times
Was thanked: 1286 time(s) in 1193 post(s)
Thanks, this is extremely useful! From the information you've given me, I have three theories:

1. The memory leak is caused by the NCrunch code running inside the build host (I hope this is the case as the problem should then be fixable).

2. The memory leak is being caused by build tasks being invoked by NCrunch

3. It's both

I've yet to see the same behaviour on any of my test solutions, so this suggests that the problem is either specific to your solution or is more noticeable with it.

I'll note down to conduct a bit of a review to see if I can find any leaks during a standard build process. I'll also look at adding a resource monitor that will recycle the build host when its memory utilisation reaches a certain point (as this is fairly cheap to do).


Thanks again.
Back to top
johnmwright
#6 Posted : Thursday, June 28, 2012 12:36:51 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 9/27/2011(UTC)
Posts: 45
Location: Chicago, IL

Thanks: 3 times
Was thanked: 7 time(s) in 6 post(s)
Two more quick notes:

1) I notice that NCrunch shows the "Abnormal runtime assembly reference resolution detected" message for my test assembly. I haven't figured out why yet, and tests run fine. Not sure if this is related to the memory issues.

2) I had a company meeting yesterday, during which VS was sitting idle. Before the meeting, each BuildHost process was sitting around 250KB. After the 4 1/2 hour meeting, they had both decreased about 2KB. So memory growth is definitely not occurring when changes are idle. (I didn't expect otherwise, but always good to check your assumptions).
Back to top
Remco
#7 Posted : Thursday, June 28, 2012 9:36:37 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,123

Thanks: 957 times
Was thanked: 1286 time(s) in 1193 post(s)
Thanks. I also don't think that the abnormal resolution would have any impact on your memory usage - and if your tests run fine, then you can probably ignore this warning.

The build host doesn't really do anything when the NCrunch queue is empty of build tasks. Most likely the leak is being caused by the build steps themselves, so you'll probably be able to reproduce it by continuing to right-click on a project in your Tests Window and choosing to rebuild it.
Back to top
Remco
#8 Posted : Monday, August 13, 2012 4:30:53 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,123

Thanks: 957 times
Was thanked: 1286 time(s) in 1193 post(s)
For anyone interested, NCrunch 1.41b has just been released including a new configuration option designed to limit the memory consumption by NCrunch build processes. While this doesn't stop the memory from 'leaking' as a result of the build, it will allow NCrunch to regularly recycle the build processes thus preventing the memory consumption from being a problem.

By default, the configuration option is set to limit build process usage to a maximum of 125MB.
Back to top
Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.050 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download