Implications of using a helper thread for debugging

re: Implications of using a helper thread for debugging

Dmitriy Zaslavskiy — Mon, 18 Oct 2004 21:14:00 GMT

Are there any changes planned in this regard.
In Longhorn or even before where most (for different values of the work most) processes will be managed an extra thread per processes will add up?

re: Implications of using a helper thread for debugging

Mike Stall — Mon, 18 Oct 2004 22:10:00 GMT

Definitely an issue. Now I know 2 wrongs don't make a right, but fwiw, Managed apps already spin up extra threads. For eg, Every app has a finalizer thread too. And certain interesting activities will also create extra threads under the covers.

For the debugger's thread: The challenge is to delay-create the helper thread without breaking the attach scenario.
We'd like to use something like kernel32!CreateRemoteThread, but that doesn't always work (such as creating across sessions).

Unfortunately, I can't yet make any official comment of what it will be when we ship v2.0.

re: Implications of using a helper thread for debugging

Dmitriy Zaslavskiy — Tue, 19 Oct 2004 18:12:00 GMT

>> Managed apps already spin up extra threads.
Sure, timers come to mind. But I would consider all or most of those uses in need of an optimization. For example Chris Brumme discussed the use of thread pool to schedule finalizers.

What about a fault injection technique. So that external debugger does something similar to GC to find a safe point and inject an exception which when CLR would handle would start debugging thread.

I do realize it's much easier to give a free advise than to implement ;)

All The News That Is Fit To Print (Oct 19, 2004)

OdeToCode Link Blog — Wed, 20 Oct 2004 05:48:00 GMT

re: Implications of using a helper thread for debugging

Mike Stall — Thu, 21 Oct 2004 08:58:00 GMT

The dilemma is finding a technique that is *guaranteed* to work in all situations (even the goofy ones), else you'll hit cases where your app crashes and you can't attach to it.

Your raise some interesting points.
The fault injection requires that we be guaranteed to find a thread that we can hijack. This may not be a given if threads are all out in the system calls or if the thread has its own handlers in place that we can't intercept.

There's also an issue of reliability. If our technique for creating the thread remotely is too random, then it may introduce too many corner cases and we may not be able to test them all sufficiently to be confident it really works properly. I'll spend the rest of my life chasing down random "attach failed to create the helper thread" bugs!

How do Managed Breakpoints work?

Mike Stall's .NET Debugging Blog — Wed, 29 Dec 2004 06:26:00 GMT

Special threads in CLR

Yun Jin's WebLog — Tue, 12 Jul 2005 21:32:23 GMT

Question: How many threads does a typical managed process have when it just starts to run?&nbsp;&nbsp;...

How many threads does a typical managed process have when it just starts to run?

C#, VS Deployment and all geek talk — Thu, 18 Aug 2005 19:33:07 GMT

Special threads in CLR

Yun Jin's WebLog — Sun, 28 Aug 2005 22:44:57 GMT

Question: How many threads does a typical managed process have when it just starts to run?&nbsp;&nbsp;...

Out-of-band events and Mixed-mode debugging

Mike Stall's .NET Debugging Blog — Tue, 13 Sep 2005 18:10:13 GMT

Interop-debugging splits all debug events into "In-band (IB) " and "Out-of-band (OOB)". Inband events...

ICorDebug reentrancy

Mike Stall's .NET Debugging Blog — Mon, 19 Sep 2005 09:50:03 GMT

ICorDebug (ICD) in managed-only debugging mode does not need to be a reentrant API. In other words, you...

What to expect when you Attach, Async-Break

Mike Stall's .NET Debugging Blog — Tue, 21 Mar 2006 19:14:50 GMT

Don't assume that if you have a thread doing a spin-wait, that you can attach / asynchronously-break...

Caveats about managed JIT-debugging

Mike Stall's .NET Debugging Blog — Mon, 24 Jul 2006 18:15:54 GMT

I received some questions in the mailbag about what Debugger.Launch actually does. Debugger.Launch the...

Trivia about Managed debugging and Exit Process

Mike Stall's .NET Debugging Blog — Thu, 10 May 2007 06:52:10 GMT

Process Shutdown is evil , as Raymond Chen recently blogged about in wonderful detail. This prompts me

ICorDebug re-architecture in CLR 4.0

Rick Byers — Sat, 01 Nov 2008 03:10:13 GMT

In my previous post I mentioned that CLR 4.0 will support managed dump debugging through ICorDebug, and

How to debug component written in VS2003 in a VS2005 application | keyongtech

How to debug component written in VS2003 in a VS2005 application | keyongtech — Sun, 18 Jan 2009 19:24:06 GMT

PingBack from http://www.keyongtech.com/613511-how-to-debug-component-written