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

Notification

Icon
Error

Remote server: Devvenv.exe choked (when receiving data from grid node server?)
GreenMoose
#1 Posted : Wednesday, March 12, 2014 9:16:50 AM(UTC)
Rank: Advanced Member

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

Thanks: 145 times
Was thanked: 66 time(s) in 64 post(s)
My vstudio 2012 choked cpu for some minutes or so and was unresponsive (I was focusing on some web stuff and only noticed it when I toggled back to vstudio). The below stack trace shows the cpu consumption used.
Is this expected behavior?

Quote:

> System.dll!System.Net.Sockets.Socket.Receive(byte[] buffer, int offset, int size, System.Net.Sockets.SocketFlags socketFlags, out System.Net.Sockets.SocketError errorCode) + 0xbd bytes
System.dll!System.Net.Sockets.Socket.Receive(byte[] buffer, int offset, int size, System.Net.Sockets.SocketFlags socketFlags) + 0x1d bytes
System.dll!System.Net.Sockets.NetworkStream.Read(byte[] buffer, int offset, int size) + 0x83 bytes
nCrunch.Core.dll!nCrunch.Core.Grid.Connectivity.DecryptorStream.Read(byte[] buffer, int offset, int count) + 0x423 bytes
nCrunch.Core.dll!nCrunch.Core.Grid.Connectivity.BidirectionalStream.Read(byte[] buffer, int offset, int count) + 0x28 bytes
nCrunch.Core.dll!#=qlV9H37gAKJQt6nX32$2ZFhXN_5XywDtXl4ovYfq$PgDFz0GQhPucyrYnvEGhXJa42SBIqICLxI1aIwYBbFXhfg==.Read(byte[] #=qVJGyH8HuhnhyZetms_Cv_A==, int #=qI3Es5zlEy_LnzD8HyYmPSg==, int #=q3jy1T54ovl$cKOaAmVHlTg==) + 0x155 bytes
nCrunch.Core.dll!nCrunch.Core.Grid.Connectivity.Zlib.DeflateStream.Read(byte[] buffer, int offset, int count) + 0x39 bytes
nCrunch.Core.dll!nCrunch.Core.Grid.Connectivity.BidirectionalStream.Read(byte[] buffer, int offset, int count) + 0x28 bytes
mscorlib.dll!System.IO.Stream.BeginReadInternal.AnonymousMethod__a(object param0) + 0x3c bytes
mscorlib.dll!System.Threading.Tasks.Task<int>.InnerInvoke() + 0x49 bytes
mscorlib.dll!System.Threading.Tasks.Task.Execute() + 0x2e bytes
mscorlib.dll!System.Threading.Tasks.Task.ExecutionContextCallback(object obj) + 0x15 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.Tasks.Task.ExecuteWithThreadLocal(ref System.Threading.Tasks.Task currentTaskSlot) + 0xcb bytes
mscorlib.dll!System.Threading.Tasks.Task.ExecuteEntry(bool bPreventDoubleExecution) + 0xb3 bytes
mscorlib.dll!System.Threading.Tasks.Task.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem() + 0x7 bytes
mscorlib.dll!System.Threading.ThreadPoolWorkQueue.Dispatch() + 0x149 bytes
mscorlib.dll!System.Threading._ThreadPoolWaitCallback.PerformWaitCallback() + 0x5 bytes



Submitted a bug report since errors were displayed in output when devstudio became responsive again; "Ceasing to send messages because of an error (was the connection closed?): nCrunch.Core.Grid.Connectivity.Zlib.ZlibException: Something is fishy. [stream error]"
(I was attached to the process so maybe this error is due to internal timeout or similar while having processed paused in other debugger?)
Remco
#2 Posted : Wednesday, March 12, 2014 10:34:06 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,

I think this is more of a symptom of the problem rather than its direct cause. The stack trace above shows an exception being thrown while trying to read data from a remote grid server. All communication with grid servers happens using background threads, so there's no way this would have been the cause of unresponsive behaviour in VS. Most likely, something went wrong inside VS which caused interference with the connection (resulting in timeout and subsequent disconnection).

Of particular interest during VS lockups is the working of the UI thread. If the UI thread is sitting inside managed code and provides no stack information, then its a safe bet that NCrunch isn't involved as NCrunch does not run unmanaged code inside the IDE. If this happens again, see if you can get a stack trace for the main/UI thread.
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.037 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download