2012-11-14 7 views
6

Ich war an Chrom Thread Stacks suchen, wenn ich, dass viele Threads bemerkte eine Spur ähnlich wie diese haben:Was macht ovly_debug_event in Chrome?

0, wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0 
1, wow64cpu.dll!TurboDispatchJumpAddressEnd+0x4a8 
2, wow64.dll!Wow64SystemServiceEx+0x1ce 
3, wow64.dll!Wow64LdrpInitialize+0x429 
4, ntdll.dll!RtlIsDosDeviceName_U+0x24c87 
5, ntdll.dll!LdrInitializeThunk+0xe 
6, ntdll.dll!ZwWaitForSingleObject+0x15 
7, kernel32.dll!WaitForSingleObjectEx+0x43 
8, kernel32.dll!WaitForSingleObject+0x12 
9, chrome.dll!ovly_debug_event+0x16574 
10, chrome.dll!ovly_debug_event+0x14904 
11, chrome.dll!ovly_debug_event+0x14826 
12, chrome.dll!ovly_debug_event+0x16d19 
13, chrome.dll!ovly_debug_event+0x1bea1b 
14, chrome.dll!ovly_debug_event+0xe8ff4 
15, chrome.dll!ovly_debug_event+0x16b50 
16, chrome.dll!ovly_debug_event+0x16ab2 
17, kernel32.dll!BaseThreadInitThunk+0x12 
18, ntdll.dll!RtlInitializeExceptionChain+0x63 
19, ntdll.dll!RtlInitializeExceptionChain+0x36 

Die Chromquelle hat den folgenden Code in sel_ldr.c die ovly_debug_event als eine fast leere Funktion zu erklären scheint :

void _ovly_debug_event (void) { 
#ifdef __GNUC__ 
    /* 
    * The asm volatile is here as instructed by the GCC docs. 
    * It's not enough to declare a function noinline. 
    * GCC will still look inside the function to see if it's worth calling. 
    */ 
    __asm__ volatile (""); 
#elif NACL_WINDOWS 
    /* 
    * Visual Studio inlines empty functions even with noinline attribute, 
    * so we need a compile memory barrier to make this function not to be 
    * inlined. Also, it guarantees that nacl_global_xlate_base initialization 
    * is not reordered. This is important for gdb since it sets breakpoint on 
    * this function and reads nacl_global_xlate_base value. 
    */ 
    _ReadWriteBarrier(); 
#endif 
} 

static void StopForDebuggerInit (uintptr_t mem_start) { 
    /* Put xlate_base in a place where gdb can find it. */ 
    nacl_global_xlate_base = mem_start; 

    NaClSandboxMemoryStartForValgrind(mem_start); 

    _ovly_debug_event(); 
} 

Dies wirft die Frage auf: Warum Chrom, das und ist fast leer für das Debuggen nur in Chrom scheint so viel Zeit in einer Funktion zu verbringen?

Antwort

4

Beachten Sie die massiven Offsets wie 0x16574 in diese Funktion. Es scheint, dass Sie keine privaten Symbole für die Datei "chrome.dll" haben, sodass der Debugger das nächstgelegene (also am ehesten nächste) öffentlich exportierte Symbol findet.

Mit anderen Worten, Sie sind nicht in _ovly_debug_event. Sie befinden sich in einer Funktion, die in der ausführbaren Datei dahinter angeordnet wurde, aber nicht öffentlich exportiert wird.

Um zu versuchen, dieses Problem zu beheben, wenn Sie sehen wollen, was tatsächlich passiert ist, Sie http://chromium-browser-symsrv.commondatastorage.googleapis.com zu Ihrem Symbolpfad hinzufügen. In windbg würde der Befehl

sein

.sympath + SRV * C: \ tmp * http://chromium-browser-symsrv.commondatastorage.googleapis.com