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

Notification

Icon
Error

VStudio2012 freeze with NCrunch "stuck in build"
GreenMoose
#1 Posted : Monday, January 20, 2014 7:38:28 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 6/17/2012(UTC)
Posts: 503

Thanks: 142 times
Was thanked: 66 time(s) in 64 post(s)
v2.1.0.2. Got back to work, started work as usually, noticed a laggy behavior and after changing ~5 lines of codes vstudio froze and becmae unresponsive. One thread is eating cpu and the callstack for that is below (killed devenv.exe after ~20min):

Quote:

[Managed to Native Transition]
> Microsoft.VisualStudio.Shell.10.0.dll!Microsoft.VisualStudio.Shell.ServiceProvider.GetService.AnonymousMethod__0() + 0x5f bytes
Microsoft.VisualStudio.Shell.10.0.dll!Microsoft.VisualStudio.ErrorHandler.CallWithCOMConvention.AnonymousMethod__0() + 0xb bytes
Microsoft.VisualStudio.Shell.10.0.dll!Microsoft.VisualStudio.ErrorHandler.CallWithCOMConvention(System.Func<int> method) + 0x2e bytes
Microsoft.VisualStudio.Shell.10.0.dll!Microsoft.VisualStudio.ErrorHandler.CallWithCOMConvention(System.Action method) + 0x4a bytes
Microsoft.VisualStudio.Shell.10.0.dll!Microsoft.VisualStudio.Shell.ServiceProvider.GetService(System.Guid guid, System.Type serviceType) + 0x12f bytes
Microsoft.VisualStudio.Shell.10.0.dll!Microsoft.VisualStudio.Shell.ServiceProvider.GetService(System.Type serviceType) + 0x59 bytes
Microsoft.VisualStudio.Shell.10.0.dll!Microsoft.VisualStudio.Shell.Package.GetService(System.Type serviceType) + 0x31b bytes
Microsoft.VisualStudio.Shell.10.0.dll!Microsoft.VisualStudio.Shell.Package.System.IServiceProvider.GetService(System.Type serviceType) + 0x5 bytes
Microsoft.VisualStudio.Shell.10.0.dll!Microsoft.VisualStudio.Shell.VsShellUtilities.IsSolutionBuilding(System.IServiceProvider serviceProvider) + 0x24 bytes
nCrunch.VSIntegration2010.dll!nCrunch.VSIntegration2010.CrunchPackage.IsSolutionBuilding.get() + 0x1b bytes
nCrunch.VSAddIn.dll!nCrunch.VSAddIn.VsHostingEnvironment.IsIDEBuildInProgress.get() + 0x32 bytes
nCrunch.Client.dll!nCrunch.Client.Processing.TaskObstructionMonitor.HoldTaskUntilExecutionIsAllowed(nCrunch.Client.Processing.LocalProcessingTask task) + 0x2b bytes
nCrunch.Client.dll!nCrunch.Client.Processing.ProcessingQueue.#=qg2uqFhD0YsQQmBWNlceLLA==(nCrunch.Client.Processing.LocalProcessingTask #=qGPM6jHtMFF2uv_oHXxY20g==) + 0x2e bytes
nCrunch.Client.dll!nCrunch.Client.Processing.ProcessingQueue.#=qEcNRexg5DS48dDfpH4Opb9eHs8EscEJvDIwnWAe_d4c=.#=qSYjaF1rpbnLUsQFXG96F9kwU92zhrfg5ccQTPQp8VkE=() + 0x15 bytes
nCrunch.Core.dll!nCrunch.Core.Threading.PooledWorkItem.Start() + 0x55 bytes
nCrunch.Core.dll!nCrunch.Core.Threading.ThreadFactory.#=qMvKXKdSMCnKSB105_cbGWA==(object #=q6YaRFIL5tyaZpPiLr7RWMQ==) + 0x59 bytes
mscorlib.dll!System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(object state) + 0x3e bytes
mscorlib.dll!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) + 0xa7 bytes
mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) + 0x16 bytes
mscorlib.dll!System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem() + 0x60 bytes
mscorlib.dll!System.Threading.ThreadPoolWorkQueue.Dispatch() + 0x149 bytes
mscorlib.dll!System.Threading._ThreadPoolWaitCallback.PerformWaitCallback() + 0x5 bytes
[Native to Managed Transition]

Remco
#2 Posted : Monday, January 20, 2014 9:32:13 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,982

Thanks: 931 times
Was thanked: 1257 time(s) in 1170 post(s)
Hi,

Thanks for sharing the stack trace ... You did well digging this up and correlating it with the lag.

Did VS become completely unresponsive for the whole 20 minutes? Or did it just run really slow?

Is this happening for you consistently?

The rough edge with this issue is that because it's being caused from inside Visual Studio, it may be tough to deduct how to properly solve it.
GreenMoose
#3 Posted : Monday, January 20, 2014 9:41:54 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 6/17/2012(UTC)
Posts: 503

Thanks: 142 times
Was thanked: 66 time(s) in 64 post(s)
Quote:
Did VS become completely unresponsive for the whole 20 minutes? Or did it just run really slow?

Completely unresponsive (got the OS "wait for application to respond"/"Close application" options in the "application is not responding" popup).
I did kill that thread (versus killing devenv.exe) and noticed RS's dialog "Performing code cleanup" before the devenv.exe finally crashed. Don't know if that is related.

Quote:
Is this happening for you consistently?

No, first time. I do have some occasional issues where editing code is very laggy and I notice a build process is currently running at NCrunch. I have sliding build delay set to 5 000ms, but when NRcunch kicks of a build it does not immediately stop when I start to type so it seems in those cases the running build process is causing the lag.

(Building on RAMDisk)
Remco
#4 Posted : Monday, January 20, 2014 9:46:11 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,982

Thanks: 931 times
Was thanked: 1257 time(s) in 1170 post(s)
My suspicion is that this was caused by a thread safety issue. I'll have a look at this from the NCrunch side, as there may be something I can do about it. Thanks for reporting it.

I'm curious about the lag you're receiving in your IDE while running NCrunch. I have observed before IDE sluggishness caused by heavy garbage collection inside the Visual Studio process. This tends to correlate with heavy tasks (such as building and running big tests) and having lots of open windows in the IDE, as the more memory is allocated, the more the garbage collector needs to compact.

Make sure you're using the latest version of Resharper. Also, disable any unnecessary features in Resharper or other packages that may contribute to surplus memory allocation.

Keeping NCrunch UI windows closed will also help. Where you need to keep them open (i.e. Tests Window), make sure you have filters set so the visible data size is small.

It may be worth running perfmon to check whether the Visual Studio process is spending large amounts of time in garbage collection.

I've been looking at ways of solving this, although the best option at the moment seems to be moving the NCrunch engine out of the Visual Studio process, which is a major piece of work :(
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