2010-10-10 5 views
5

J'ai un programme de test simple provoquant une attente infinie au verrouillage. Donc le thread principal est fondamentalement verrouillé quand il essaie de faire Monitor.Enter (sync). Si j'ai regardé! ClrStack sur le thread principal, sa sortie montre essentiellement ce qui a du sens mais quand j'essaie de voir le côté natif de la pile, je m'attends à voir un certain type d'appel d'objet unique/multiple mais je ne vois pas il. Quelqu'un peut-il l'expliquer. MerciLa trace de la pile d'appel native de Windbg n'a pas de sens

0:000> !CLRStack 

symbole APB pour mscorwks.dll non chargé
OS TID: 0x1e8 (0)
ESP EIP
0012f0a8 77455e74 [GCFrame: 0012f0a8]
0012f178 77455e74 [HelperMethodFrame_1OBJ: 0012f178] système. Threading.Monitor.Enter (System.Object) 0012f1d0 00a40177 ConsoleApplication1.Program.Main (System.String [])
0012f400 70fc1b4c [GCFrame: 0012f400]
0: 000> kb
ChildEBP RetAddr Args to Child
AVERTISSEMENT: les informations de déroulement de pile ne sont pas disponibles. Les images suivantes peuvent être erronées.
0012eeb4 710afb92 0012ee68 002d6280 00000000 ntdll! KiFastSystemCallRet
0012ef1c 710af7c3 00000001 002d6280 00000000 mscorwks! StrongNameFreeBuffer + 0x1b1f2
0012ef3c 710af8cc 00000001 002d6280 00000000 mscorwks! StrongNameFreeBuffer + 0x1ae23
0012efc0 710af961 00000001 002d6280 00000000 mscorwks! StrongNameFreeBuffer + 0x1af2c
0012f010 710afae1 00000001 00000000 002d6280 mscorwks! StrongNameFreeBuffer + 0x1afc1
0012f06c 70fdc5ae FFFFFFFF 00000001 00000000 mscorwks! StrongNameFreeBuffer + 0x1b141
0012f080 710df68a FFFFFFFF 00000001 00000000 mscorwks! LogHelp_NoGuiOnAssert + 0x10562
0012f10c 710b1154 002aad90 FFFFFFFF 002aad90 mscorwks! StrongNameFreeBuffer + 0x4acea
0012f128 710b10d8 42b8b47d 00000000 002aad90 mscorwks! StrongNameFreeBuffer + 0x1c7b4
0012f1e0 70fc1b4c 0012f1f0 0012f230 0012f270 mscorwks! StrongNameFreeBuffer + 0x1c738
0012f1f0 70fd2219 0012f2c0 00000000 0012f290 mscorwks + 0x1b4c
0012f270 70fe6591 0012f2c0 00000000 0012f290 mscorwks! LogHelp_NoGuiOnAssert + 0x61cd
0012f3ac 70fe65c4 0023c038 0012f478 0012f444 mscorwks! CoUninitializeEE + 0x2ead
0012f3c8 70fe65e2 0023c038 0012f478 0012f444 mscorwks! CoUninitializeEE + 0x2ee0
0012f3e0 7103389d 0012f444 42b8b0f1 00000000 mscorwks! CoUninitializeEE + 0x2efe
0012f544 710337bd 002332e0 00000001 0012f580 mscorwks! GetPrivateContextsPerfCounters + 0xf546
0012f7ac 71033d0d 00000000 42b8b9c9 00000001 mscorwks! GetPrivateContextsPerfCounters + 0xf466
0012fc7c 71033ef7 00ce0000 00000000 42b8979 mscorwks! GetPrivateContextsPerfCounters + 0xf9b6
0012fccc 71033e27 00ce0000 42b8b8a1 00000000 mscorwks! CorExeMain + 0x168
* ERREUR: le fichier de symboles n'a pas pu être trouvé. Par défaut pour exporter des symboles pour C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ mscoreei.dll - 0012fd14 71cf55ab 71033d8f 0012fd30 71f37f16 mscorwks!CorExeMain + 0x98
*
ERREUR: le fichier de symboles n'a pas pu être trouvé. Défaillant exporter des symboles C:! \ Windows \ system32 \ mscoree.dll -
0012fd20 71f37f16 00000000 71cf0000 0012fd44 mscoreei CorExeMain + 0x38
0012fd30 71f34de3 00000000 7723d0e9 7ffd8000 Mscoree CreateConfigStream + 0x13f
0012fd44 774319bb 7ffd8000 084952f9 00000000 Mscoree CorExeMain + 0x8
0012fd84 7743198e 71f34ddb 7ffd8000 00000000 ntdll! RtlInitializeExceptionChain + 0x63
0012fd9c 00000000 71f34ddb 7ffd8000 00000000 ntdll! RtlInitializeExceptionChain + 0x36

Répondre

4

Vous devez pointer windbg à Microsoft Windows serveur symboles pour obtenir une bonne trace de la pile.

type dans ce qui suit dans la fenêtre de votre commande windbg:

.sympath srv*c:\websymbols*http://msdl.microsoft.com/download/symbols

Voir aussi ceci:

Using microsoft symbol server to get symbols

En outre, pour répondre à votre question initiale sur la façon de déboguer ce, voici le livre de cuisine:

 
0:000> !clrstack 
OS Thread Id: 0x1358 (0) 
ESP  EIP  
0012f328 7c90e514 [GCFrame: 0012f328] 
0012f3f8 7c90e514 [HelperMethodFrame_1OBJ: 0012f3f8] System.Threading.Monitor.Enter(System.Object) 
0012f450 00d10177 Program.Main(System.String[]) 
0012f688 79e71b4c [GCFrame: 0012f688] 

Dans votre programme original, le bac Le thread kground a été démarré en premier. Donc, il a acquis le verrou. Cependant, il est sorti sans relâcher le verrou. Après que votre fil principal a essayé d'acquérir le verrou et il est bloqué parce que le verrou est déjà possédé.

Comment trouvez-vous à qui il appartient? D'abord faire un! Threads suivi de! Syncblk.

 
0:000> !threads 
ThreadCount: 3 
UnstartedThread: 0 
BackgroundThread: 1 
PendingThread: 0 
DeadThread: 1 
Hosted Runtime: no 
             PreEmptive GC Alloc   Lock 
     ID OSID ThreadOBJ State  GC  Context  Domain Count APT Exception 
    0 1 1358 0014bb00 200a020 Enabled 00000000:00000000 001540d0  0 MTA 
    2 2 1360 0015e320  b220 Enabled 00000000:00000000 001540d0  0 MTA (Finalizer) 
XXXX 3 0 00175a98  9820 Enabled 00000000:00000000 001540d0  1 Ukn 
0:000> !syncblk 
Index SyncBlock MonitorHeld Recursion Owning Thread Info SyncBlock Owner 
    2 0017903c   3   1 00175a98  0 XXX 013503cc SyncBlock 
----------------------------- 
Total   2 
CCW    0 
RCW    0 
ComClassFactory 0 
Free   0 

Comme vous pouvez le voir,! Syncblk dit que l'objet de fil de owining est 00175a98. À partir de la sortie! Threads, vous pouvez voir que l'objet de thread 00175a98 est le thread mort qui est sorti tout en possédant le verrou.

Espérons que cela aide.

+0

Pointant vers le serveur de symboles a résolu le problème lié à la sortie kb mais je ne suis toujours pas sûr de votre réponse à ma question d'un autre lien. Je vais ajouter mon commentaire sur ce lien. Merci – imak

Questions connexes