Discovering which critical sections threads are in

Mike Hearn m.hearn at signal.qinetiq.com
Wed Jun 11 10:00:31 CDT 2003


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

-- 
Mike Hearn <m.hearn at signal.qinetiq.com>
QinetiQ - Malvern Technology Center




More information about the wine-devel mailing list