derekbruening
commented
9 years ago From bruen...@google.com on July 20, 2012 08:49:35
summarizing a conversation with Qin where I brought up the possibility of gdi32.dll creating and freeing GDI-related data (so not the usual kernel "GDI objects"/"GDI handles", but GDI resources nonetheless), given that the Select library calls skip the corresponding syscalls ( issue #764 ) and update the user-smode GDI table state instead. the question was, would it be better to detect leaks by looking at the user-mode table, if it's more likely there's data in there that's not created via syscall than that syscalls are invoked w/o going through the table. the conclusion is: even if there are solely user-space gdi objects and they constitute enough of a fraction of "gdi object usage" by apps that we want to detect their leaks, walking the table is not enough b/c we want to report callstack of creation: so in that scenario of solely user-space objects we would keep the syscall interception and just add library interception later.
Owner: zhao...@google.com
From bruen...@google.com on January 18, 2012 17:23:57
xref issue #752 xref issue #188 GDI handles are all stored in PEB->GdiSharedHandleTable (for wow64 need to look at the x64 table)
this issue covers detecting leaks of GDI handles.
xref http://msdn.microsoft.com/en-us/magazine/cc188782.aspx note that the 64-bit table entry is 0x18 bytes
Original issue: http://code.google.com/p/drmemory/issues/detail?id=756