Discovering which critical sections threads are in

[Mike Hearn]

Hi all,

I'm trying to debug a deadlock I get when trying to open the print
dialog in Internet Explorer, the backtrace I get looks like this:

=>0 0x420cdb44 (NTDLL.DLL.memcpy+0x516f4) (ebp=435f0c54)
  1 0x400b8d2f (NTDLL.DLL.NtWaitForMultipleObjects+0x133 in
libntdll.dll.so) (ebp=435f0cf0)
  2 0x400b7557 (usr1_handler+0x3b(__signal=0xa, __context=0x4f)
[signal_i386.c:1132] in libntdll.dll.so) (ebp=435f0d1c)
  3 0x42028c48 (NTDLL.DLL.toupper+0x6748) (ebp=437126e8)
  4 0x400b8d2f (NTDLL.DLL.NtWaitForMultipleObjects+0x133 in
libntdll.dll.so) (ebp=43712784)
  5 0x400b8d59 (NtWaitForSingleObject+0x25(handle=0x260, alertable=0x0,
timeout=0x437127c0) [sync.c:594] in
libntdll.dll.so) (ebp=437127a4)
  6 0x400a6e53 (RtlpWaitForCriticalSection+0xdb(crit=0x70460350)
[critsection.c:162] in libntdll.dll.so) (ebp=43712828)
  7 0x400a7020 (RtlEnterCriticalSection+0x34(crit=0x70460350)
[critsection.c:1920] in libntdll.dll.so) (ebp=4371283c)
  8 0x70457e56 (MLANG.DLL.ConvertINetString+0x4f85 in
C:\WINDOWS\SYSTEM\MLANG.DLL) (ebp=4371286c)
  9 0x70eaf851
(MSHTML.DLL.com_ms_osp_ospmrshl_releaseByValExternal+0x82912 in
C:\WINDOWS\SYSTEM\MSHTML.DLL) (ebp=43712990)
  10 0x70e60c0f
(MSHTML.DLL.com_ms_osp_ospmrshl_releaseByValExternal+0x33cd0 in
C:\WINDOWS\SYSTEM\MSHTML.DLL) (ebp=43712a2c)
  11 0x70d94e1c (MSHTML.DLL.EntryPoint+0xbd49 in
C:\WINDOWS\SYSTEM\MSHTML.DLL) (ebp=43712a4c)
  12 0x70cbe59f (MSHTML.DLL..text+0x6d59f in
C:\WINDOWS\SYSTEM\MSHTML.DLL) (ebp=43712a6c)
  13 0x70d570e3 (MSHTML.DLL.DllGetClassObject+0x17b2f in
C:\WINDOWS\SYSTEM\MSHTML.DLL) (ebp=43712ce4)
  14 0x70d3bff7 (MSHTML.DLL.DllCanUnloadNow+0x28c44 in
C:\WINDOWS\SYSTEM\MSHTML.DLL) (ebp=43712d50)
  15 0x70e2621d (MSHTML.DLL.CreateHTMLPropertyPage+0x41f87 in
C:\WINDOWS\SYSTEM\MSHTML.DLL) (ebp=43712d8c)
  16 0xffffffff (OLE32.DLL..reloc+0x80018fff) (ebp=00000000)

The null ebp at the top is kind of odd, I think this stack might be the
result of a demarshalled RPC call. But anyway. As you can see it's
blocking on a critical section, but I don't know how to find out which
thread has got suck inside it. I tried putting trace statements in
Rtl(Enter/Leave)CriticalSection, oops, not a good idea, waaaay too much
spew there to be useful.

So, what I'd like to know is whether there is any way to find out which
thread has entered that critical section. Also, is this even a good
idea, or is there a better way to debug thread deadlocks?

thanks -mike

[Eric Pouech]

> The null ebp at the top is kind of odd, I think this stack might be the
> result of a demarshalled RPC call. But anyway. As you can see it's
> blocking on a critical section, but I don't know how to find out which
> thread has got suck inside it. I tried putting trace statements in
> Rtl(Enter/Leave)CriticalSection, oops, not a good idea, waaaay too much
> spew there to be useful.
>
> So, what I'd like to know is whether there is any way to find out which
> thread has entered that critical section. Also, is this even a good
> idea, or is there a better way to debug thread deadlocks?
>
> thanks -mike

normally there's a message printed out when a critsect times out like:
section 0x12345678 myCS wait timed out, retrying (60 sec) tid=xxxx
and the tid gives you the thread id of the thread holding the cs
then, you can use it for example in 'bt <tid>' to get a backtrace of 
that particular thread and look at what it's doing

A+

[Mike Hearn]

On Wed, 11 Jun 2003 22:31:39 +0200, Sir Eric Pouech scribed thus:
> normally there's a message printed out when a critsect times out like:
> section 0x12345678 myCS wait timed out, retrying (60 sec) tid=xxxx
> and the tid gives you the thread id of the thread holding the cs
> then, you can use it for example in 'bt <tid>' to get a backtrace of 
> that particular thread and look at what it's doing

Yup, sure, I know how to do that. But the backtrace tells you which thread
blocked, and where it was when it blocked. It doesn't tell you which
thread is already inside it (so you can go find out why it never left).

In the end yesterday I just stuck some trace statements in and used emacs
to process the resulting huge file :) i feel there should be a better way
though.... maybe having a linked list of RTL_CRITICAL_SECTION structs that
the debugger can walk.