| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is still valid
with a VirtualQuery call.
This fixes http://code.google.com/p/chromium/issues/detail?id=7701
Bug=7701
Review URL: http://codereview.chromium.org/21434
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9929 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If IATPatchFunction::Unpatch fails during RestoreImportedFunction
it means that we cannot safely unpatch the import address table
patch. In this case its better to be hands off the intercept as
trying to unpatch again in the destructor of IATPatchFunction is
not going to be any safer.
In real world, when we patch a plugin's SetCursor, we intercept
npswf.dll's IAT entry of SetCursor. It seems that our unpatch
fails when the plugin ref count goes to 0. It could be because
some one else has patched on top of us. Then, during CRT
uninitialization at process shutdown, the destructor of
IATPatchFunction is called. It detects that we haven't unpatched
yet and tries to unpatch. But at this time the plugin DLL is
unloaded and the IAT thunk is invalid. There's no point in
trying to unpatch unloaded DLL's IAT :)
BUG=6886
Review URL: http://codereview.chromium.org/21044
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9142 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1287 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8 0039d316-1c4b-4281-b951-d872f2087c98
|
