derekbruening
commented
10 years ago From bruen...@google.com on January 12, 2012 11:37:45
wow looks like I pasted too much stuff into the initial entry text above
xref issue #568 (parallelize leak scan) xref issue #711 (improve callstack walk)
\ INFO breakdown of -leaks_only -no_zero_stack on ui_tests
this is NPAPITesterBase.NPObjectProxy
Process Name 64-bit Timer samples
ntoskrnl.exe 1 45.35
dynamorio.dll 22.47
drmemorylib.dll 12.31
dbghelp.dll 10.52
ntdll.dll 3.04
wow64.dll 1 2.89
wow64cpu.dll 1 2.26
Parity.sys 1 0.4
unknown module pid (6804) 1 0.27
9 modules, Total: 19377 samples, 99.51% of shown samples
CS:EIP Symbol + Offset Timer samples
0x2903a74 PsReturnProcessPagedPoolQuota 50.04
0x289b228 PsIsProtectedProcess 24.45
0x28cb490 KeSynchronizeExecution 10.79
0x2baa350 ObReferenceObjectByHandle 8.04
0x2916c24 KeQueryPriorityThread 1.12
0x28c65f0 memmove 0.88
CS:EIP Symbol + Offset Timer samples
0x6fe9b780 mutex_unlock 15.34
0x6fe9b740 mutex_trylock 14.65
0x6fee2470 dr_mutex_lock 12.55
0x6fee24d0 dr_mutex_unlock 11.06
0x6fe9d460 mutex_lock 10.17
0x6fe611f4 dynamorio_syscall_wow64 6.17
0x6fee7290 get_thread_private_dcontext 2.9
0x6fef70b0 query_virtual_memory 2.67
0x6fea24c0 common_heap_alloc 1.51
0x6fee7b70 query_memory_ex 1.28
CS:EIP Symbol + Offset Timer samples
0x6ffe7340 rb_in_node 59.78
0x6ffe5160 check_reachability_pointer 7.55
0x6ffee6c0 hashtable_lookup 7.05
0x6ffee4b0 hash_key 6.05
0x6ffd90c0 heap_region_bounds 6.01
0x6ffe5310 check_reachability_helper 3.75
0x6ffd6cf0 get_decoded_ptr 2.21
0x6ffee00a dr_mutex_unlock 1.67
0x6ffee010 dr_mutex_lock 1.63
CS:EIP Symbol + Offset Timer samples
0x54d730 MiniDumpReadDumpStream 99.51
analysis:
- rb_in_node does highlight tree lookup as potential issue
- however, rb_in_node is 60% of 12% => 7% total. kernel is 45%. I'm not sure if the symbols in the shown breakdown are useful b/c don't have private syms. TLB miss is handled in hardware for x86 so would only be in kernel on page miss. I'm wondering if most of this is page handling during the scan.
parallelizing seems most promising for large enough apps: no synch is needed on malloc lookup since read-only at that point. synch is needed when updating leak data structs but common case is a non-heap-pointer during scan.
Owner: bruen...@google.com
Labels: -Priority-Low -Type-Defect Priority-Medium Type-Enhancement Component-LeakCheck Performance
From derek.br...@gmail.com on December 10, 2010 17:58:04
PR 475518
my initial implementation of scanning for pointers for reachability analysis produces a noticeable 1-second delay at app exit (and at nudge time for PR 428709). this case covers trying to speed that up. it's not identifying the defined region that's slow, it's the pointer scan itself.
adding to this case a FIXME from my code that may improve perf noticeably: skipping regions that have been read-only since being loaded (.text, .rodata, etc.). we'll need extra tracking since today we can't tell whether they were made writable and then changed back to read-only. we could also skip writable regions that have not been written to since being loaded since they can't point into the heap. technically the app could write a heap pointer to a file and then mmap it in but we'll ignore that.
my initial imp is going to skip r-x regions. I'm not going to skip all non-writable though. this case covers adding modified-since-load info to both avoid false neg w/ r-x and to skip more non-writable.
it does take substantial time on large apps. we should probably fix up -no_count_leaks and document it, and perhaps make it default so that nudges can be used for just updating the error summary w/o waiting 8 minutes? just turning it off today => bugs: maybe somebody else needs op_record_allocs in alloc.c. we still record for pre_us.
for PR 485354 I have the leak scan on windows skipping read-only image regions: once this case checks for history that can be done for *nix too
Server: perforce-panda.eng.vmware.com:1985
PR 520916: leak-check-only mode without losing accuracy
PR 485354: # possible leaks nondet on nudge test on Windows My leaks-only test hit PR 485354 so I investigated:
The beyond-TOS + zero-on-stack-alloc seems to be working in practice as far as I can tell (apps aren't exactly deterministic but results seem to match pretty well w/ full shadowing). Zeroing is not 100% transparent but it's close enough for me. We'll need more data on more apps but I think it's going to work out, and the overhead should be a strict subset of my original shadow-writes proposal. Unfortunately the overhead is still significant: 2.2x on crafty (vs 1.6x for DrHeapstat).
xref PR 536878: add leak checking feature to Dr. Heapstat a la Dr. Memory -leaks_only
future work under PR 539395: improve accuracy of -leaks_only:
Original issue: http://code.google.com/p/drmemory/issues/detail?id=151