Debugging

I have a situation with an apparent deadlock. I have two threads
which are blocked on the statement "lock(_SyncRoot)", where _SyncRoot
is my own private object. However, I've examined all the other
threads in my application and walked up their callstacks, and none of
them seem to be holding a lock on this object. Moreoever, I never
lock this object in any way other than using the lock keyword, and
it's never in a nested lock. So it seems to me that a deadlock is
provably not possible.

Is there some sort of debugger command that will tell me which thread
is holding the lock on this object?

Thanks

Cowboy
Tue Mar 27 14:43:36 CDT 2007

Break every time it locks that object and when it releases the lock. When it
fires a second lock, you can backtrace on the call stack and figure where to
set a breakpoint. Most likely you are calling the routine a second time
before the lock is gone or some error is preventing letting the lock loose.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

*********************************************
Think outside the box!
*********************************************
"Zachary Turner" <divisortheory@gmail.com> wrote in message
news:1175022764.359204.185390@p15g2000hsd.googlegroups.com...
>I have a situation with an apparent deadlock. I have two threads
> which are blocked on the statement "lock(_SyncRoot)", where _SyncRoot
> is my own private object. However, I've examined all the other
> threads in my application and walked up their callstacks, and none of
> them seem to be holding a lock on this object. Moreoever, I never
> lock this object in any way other than using the lock keyword, and
> it's never in a nested lock. So it seems to me that a deadlock is
> provably not possible.
>
> Is there some sort of debugger command that will tell me which thread
> is holding the lock on this object?
>
> Thanks
>

Zachary
Tue Mar 27 14:54:13 CDT 2007

Calling the routine a second time before the lock is gone shouldn't
cause a problem should it? It would simply wait at the lock statement
until the first routine releases the lock, then it will enter.
Moreover, lock statements are internally embedded in try/finally so
they are always released no matter how the block is exited.

I'm actually starting to think my system may have more severe
problems, of which this could be a side effect. Ugh.

On Mar 27, 2:43 pm, "Cowboy \(Gregory A. Beamer\)"
<NoSpamMgbwo...@comcast.netNoSpamM> wrote:
> Break every time it locks that object and when it releases the lock. When it
> fires a second lock, you can backtrace on the call stack and figure where to
> set a breakpoint. Most likely you are calling the routine a second time
> before the lock is gone or some error is preventing letting the lock loose.
>
> --
> Gregory A. Beamer
> MVP; MCP: +I, SE, SD, DBA
>
> *********************************************
> Think outside the box!
> *********************************************"Zachary Turner" <divisorthe...@gmail.com> wrote in message
>
> news:1175022764.359204.185390@p15g2000hsd.googlegroups.com...
>
>
>
> >I have a situation with an apparent deadlock. I have two threads
> > which are blocked on the statement "lock(_SyncRoot)", where _SyncRoot
> > is my own private object. However, I've examined all the other
> > threads in my application and walked up their callstacks, and none of
> > them seem to be holding a lock on this object. Moreoever, I never
> > lock this object in any way other than using the lock keyword, and
> > it's never in a nested lock. So it seems to me that a deadlock is
> > provably not possible.
>
> > Is there some sort of debugger command that will tell me which thread
> > is holding the lock on this object?
>
> > Thanks- Hide quoted text -
>
> - Show quoted text -

Jon
Tue Mar 27 14:54:41 CDT 2007

Zachary Turner <divisortheory@gmail.com> wrote:
> I have a situation with an apparent deadlock. I have two threads
> which are blocked on the statement "lock(_SyncRoot)", where _SyncRoot
> is my own private object. However, I've examined all the other
> threads in my application and walked up their callstacks, and none of
> them seem to be holding a lock on this object. Moreoever, I never
> lock this object in any way other than using the lock keyword, and
> it's never in a nested lock. So it seems to me that a deadlock is
> provably not possible.
>
> Is there some sort of debugger command that will tell me which thread
> is holding the lock on this object?

One thing you could do is replace the existing lock with a "smart" lock
as per
http://pobox.com/~skeet/csharp/miscutil/usage/locking.html
If you use an OrderedLock, it will keep track of who's got hold of it,
so you could debug it that way.

It shouldn't be too hard to replace the lock if it's only locked in a
single class, and you can put it back afterwards if you want. Of
course, you'd need to use the MiscUtil library temporarily. You can get
it from:
http://pobox.com/~skeet/csharp/miscutil

--
Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Chris
Tue Mar 27 15:51:01 CDT 2007

"Zachary Turner" <divisortheory@gmail.com> wrote
> Is there some sort of debugger command that will tell me which thread
> is holding the lock on this object?

There sure is. Unfortunatly, it only exists in WinDbg & Son of Strike - not
in Visual Studio.
http://msdn.microsoft.com/msdnmag/issues/05/07/Debugging/?topics=/msdnmag/issues/05/07/Debugging#S11

You should be able to track it down pretty quickly, once you get over the
"eeewwww!" factor that comes with WinDbg.

Generating a dump one your application is hung is pretty easy. You can read
about it either in the article I already linked, or at:
http://www.coversant.net/Coversant/Blogs/tabid/88/EntryID/28/Default.aspx

(If you're able to consistanly get your app to deadlock, you should be able
to skip the whole 'Create a Dump" step, and just run your app using WinDbg &
SOS. That makes things a bit easier.)

--
Chris Mullins, MCSD.NET, MCPD:Enterprise, Microsoft C# MVP
http://www.coversant.com/blogs/cmullins

Zachary
Tue Mar 27 16:14:48 CDT 2007

I'm familar with WinDbg already, but it only operates on primitive
windows threads. My understanding of .NET Threads is that there is no
defined mapping between a .NET Thread and the Windows thread(s) by
which it is implemented. In fact, 4 different .NET Threads may be
implemented on a single windows thread, or 1 different .NET Thread may
be implemented by 4 Windows threads. I may be wrong about that, but I
never considered the WinDbg option simply because even if I found out
which Windows thread was holding the object, I wouldn't be able to map
that back to one of my .NET threads.

On Mar 27, 3:51 pm, "Chris Mullins [MVP]" <cmull...@yahoo.com> wrote:
> "Zachary Turner" <divisorthe...@gmail.com> wrote
>
> > Is there some sort of debugger command that will tell me which thread
> > is holding the lock on this object?
>
> There sure is. Unfortunatly, it only exists in WinDbg & Son of Strike - not
> in Visual Studio.http://msdn.microsoft.com/msdnmag/issues/05/07/Debugging/?topics=/msd...
>
> You should be able to track it down pretty quickly, once you get over the
> "eeewwww!" factor that comes with WinDbg.
>
> Generating a dump one your application is hung is pretty easy. You can read
> about it either in the article I already linked, or at:http://www.coversant.net/Coversant/Blogs/tabid/88/EntryID/28/Default....
>
> (If you're able to consistanly get your app to deadlock, you should be able
> to skip the whole 'Create a Dump" step, and just run your app using WinDbg &
> SOS. That makes things a bit easier.)
>
> --
> Chris Mullins, MCSD.NET, MCPD:Enterprise, Microsoft C# MVPhttp://www.coversant.com/blogs/cmullins

Chris
Tue Mar 27 16:57:29 CDT 2007

The definition of CLR threads in the leaves room for exactly what you
describe, but today's reality is that a CLR thread & an O/S thread are the
same thing in all current implementations of the CLR. As a result, you don't
have to worry about the details of CLR threads mapped to O/S threads. I
recently confirmed this by talking to both Joe Duffy & Jeff Richter. I
talked a bit about this in this thread:
http://groups.google.com/group/microsoft.public.dotnet.framework/tree/browse_frm/thread/c37841cfe5a1dd01/cc648b16583c6fa4

Also, WinDbg, when you use Son of Strike with it, gives you all the
debugging information you need. It's loaded with stuff. When you say,
"!threads", you get a list of CLR threads, and their details.

Using WinDbg & SOS, you should be able to track this down pretty easily.

--
Chris Mullins, MCSD.NET, MCPD:Enterprise, Microsoft C# MVP
http://www.coversant.com/blogs/cmullins

"Zachary Turner" <divisortheory@gmail.com> wrote in message
news:1175030088.811425.28890@o5g2000hsb.googlegroups.com...
> I'm familar with WinDbg already, but it only operates on primitive
> windows threads. My understanding of .NET Threads is that there is no
> defined mapping between a .NET Thread and the Windows thread(s) by
> which it is implemented. In fact, 4 different .NET Threads may be
> implemented on a single windows thread, or 1 different .NET Thread may
> be implemented by 4 Windows threads. I may be wrong about that, but I
> never considered the WinDbg option simply because even if I found out
> which Windows thread was holding the object, I wouldn't be able to map
> that back to one of my .NET threads.
>
> On Mar 27, 3:51 pm, "Chris Mullins [MVP]" <cmull...@yahoo.com> wrote:
>> "Zachary Turner" <divisorthe...@gmail.com> wrote
>>
>> > Is there some sort of debugger command that will tell me which thread
>> > is holding the lock on this object?
>>
>> There sure is. Unfortunatly, it only exists in WinDbg & Son of Strike -
>> not
>> in Visual
>> Studio.http://msdn.microsoft.com/msdnmag/issues/05/07/Debugging/?topics=/msd...
>>
>> You should be able to track it down pretty quickly, once you get over the
>> "eeewwww!" factor that comes with WinDbg.
>>
>> Generating a dump one your application is hung is pretty easy. You can
>> read
>> about it either in the article I already linked, or
>> at:http://www.coversant.net/Coversant/Blogs/tabid/88/EntryID/28/Default....
>>
>> (If you're able to consistanly get your app to deadlock, you should be
>> able
>> to skip the whole 'Create a Dump" step, and just run your app using
>> WinDbg &
>> SOS. That makes things a bit easier.)
>>
>> --
>> Chris Mullins, MCSD.NET, MCPD:Enterprise, Microsoft C#
>> MVPhttp://www.coversant.com/blogs/cmullins
>
>

Cowboy
Wed Mar 28 13:34:28 CDT 2007

If it is locking the same resource, it will definitely cause a problem. :-)

The architecture for multi-threaded apps is far more complex than it seems
on the surface. I like Jon's suggestions on this one. There was also an MSDN
article a few months ago on locking strategies. If I can find it, and have
time, I will post an URL.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

*********************************************
Think outside the box!
*********************************************
"Zachary Turner" <divisortheory@gmail.com> wrote in message
news:1175025253.492672.98960@n59g2000hsh.googlegroups.com...
> Calling the routine a second time before the lock is gone shouldn't
> cause a problem should it? It would simply wait at the lock statement
> until the first routine releases the lock, then it will enter.
> Moreover, lock statements are internally embedded in try/finally so
> they are always released no matter how the block is exited.
>
> I'm actually starting to think my system may have more severe
> problems, of which this could be a side effect. Ugh.
>
> On Mar 27, 2:43 pm, "Cowboy \(Gregory A. Beamer\)"
> <NoSpamMgbwo...@comcast.netNoSpamM> wrote:
>> Break every time it locks that object and when it releases the lock. When
>> it
>> fires a second lock, you can backtrace on the call stack and figure where
>> to
>> set a breakpoint. Most likely you are calling the routine a second time
>> before the lock is gone or some error is preventing letting the lock
>> loose.
>>
>> --
>> Gregory A. Beamer
>> MVP; MCP: +I, SE, SD, DBA
>>
>> *********************************************
>> Think outside the box!
>> *********************************************"Zachary Turner"
>> <divisorthe...@gmail.com> wrote in message
>>
>> news:1175022764.359204.185390@p15g2000hsd.googlegroups.com...
>>
>>
>>
>> >I have a situation with an apparent deadlock. I have two threads
>> > which are blocked on the statement "lock(_SyncRoot)", where _SyncRoot
>> > is my own private object. However, I've examined all the other
>> > threads in my application and walked up their callstacks, and none of
>> > them seem to be holding a lock on this object. Moreoever, I never
>> > lock this object in any way other than using the lock keyword, and
>> > it's never in a nested lock. So it seems to me that a deadlock is
>> > provably not possible.
>>
>> > Is there some sort of debugger command that will tell me which thread
>> > is holding the lock on this object?
>>
>> > Thanks- Hide quoted text -
>>
>> - Show quoted text -
>
>

Zachary
Fri Mar 30 13:14:55 CDT 2007

Maybe I'm just misunderstanding what you're saying here.

Two threads A and B.

Thread A executes the code

lock(_Resource)
{
...
}

and is executing the code ...

Before Thread A exits the previously defined scope, Thread B attempts
to execute the code

lock(_Resource)
{
...
}

You're saying the app is coded incorrectly and will generate a
deadlock? If so, what is the point of the lock statement? Thread B
should wait until Thread A exits its block, then Thread B will enter
the block automatically.

On Mar 28, 1:34 pm, "Cowboy \(Gregory A. Beamer\)"
<NoSpamMgbwo...@comcast.netNoSpamM> wrote:
> If it is locking the same resource, it will definitely cause a problem. :-)
>
> The architecture for multi-threaded apps is far more complex than it seems
> on the surface. I like Jon's suggestions on this one. There was also an MSDN
> article a few months ago on locking strategies. If I can find it, and have
> time, I will post an URL.