NetInverse Developers Blog

April 9, 2009
Category: Debugging — Tags: , , , , — admin @ 10:40 am

SOS Command: GCInfo

!GCInfo (<MethodDesc address> | <Code address>)

!GCInfo is especially useful for CLR Devs who are trying to determine if there is a bug in the JIT Compiler. It parses the GCEncoding for a method, which is a compressed stream of data indicating when registers or stack locations contain managed objects. It is important to keep track of this information, because if a garbage collection occurs, the collector needs to know where roots are so it can update them with new object pointer values.

Here is sample output where you can see the change in register state. Normally you would print this output out and read it alongside a disassembly of the method. For example, the notation “reg EDI becoming live” at offset 0×11 of the method might correspond to a “mov edi,ecx” statement.

!ip2md 00ff019a
MethodDesc: 00933198

!gcinfo 00933198
entry point 00ff0160
Normal JIT generated code
GC info 131be56000931b7c
Method info block:
    method      size   = 00E3
    prolog      size   = 26
    epilog      size   =  8
    epilog     count   =  1
    epilog      end    = yes
    callee-saved regs  = EDI ESI EBX EBP
    ebp frame          = yes
    fully interruptible= yes
    double align       = no
    arguments size     =  0 DWORDs
    stack frame size   = 20 DWORDs
    untracked count    =  1
    var ptr tab count  =  8
    security check obj = yes
    exception handlers = yes
    edit & continue    = yes
    epilog        at   00DB
    argTabOffset = 1b
81 63 AD D4 B8 |
AA 94 F2 C0 C2 |
45 08 1B       | 

Pointer table:
10             |             [EBP-10H] an untracked  local
3C 2D 81 36    | 002D..00E3  [EBP-3CH] a  pointer
40 05 81 31    | 0032..00E3  [EBP-40H] a  pointer
48 15 0B       | 0047..0052  [EBP-48H] a  pointer
4C 14 28       | 005B..0083  [EBP-4CH] a  pointer
50 0D 1B       | 0068..0083  [EBP-50H] a  pointer
5C 23 1C       | 008B..00A7  [EBP-5CH] a  pointer
54 2C 08       | 00B7..00BF  [EBP-54H] a  pointer
58 18 09       | 00CF..00D8  [EBP-58H] a  pointer
F7 44          | 0044        reg EAX becoming live
F0 4C          | 0050        reg ECX becoming live
02             | 0052        reg EAX becoming dead
46             | 0058        reg EAX becoming live
08             | 0058        reg ECX becoming dead
F2 01          | 0071        reg EAX becoming dead
F1 47          | 0088        reg EAX becoming live
F1 54          | 009C        reg EDX becoming live
4B             | 009F        reg ECX becoming live
05             | 00A4        reg EAX becoming dead
08             | 00A4        reg ECX becoming dead
10             | 00A4        reg EDX becoming dead
4B             | 00A7        reg ECX becoming live
0D             | 00AC        reg ECX becoming dead
4B             | 00AF        reg ECX becoming live
45             | 00B4        reg EAX becoming live
08             | 00B4        reg ECX becoming dead
56             | 00BA        reg EDX becoming live
F0 12          | 00C4        reg EDX becoming dead
4A             | 00C6        reg ECX becoming live
0E             | 00CC        reg ECX becoming dead
F0 04          | 00D8        reg EAX becoming dead
43             | 00DB        reg EAX becoming live
F0 00          | 00E3        reg EAX becoming dead
FF             |           |

This function is important for CLR Devs, but very difficult for anyone else to make sense of it. You would usually come to use it if you suspect a gc heap corruption bug caused by invalid GCEncoding for a particular method.

No Comments »

No comments yet.

RSS feed for comments on this post. TrackBack URL

Leave a comment

©2009 NetInverse. All rights reserved. Powered by WordPress