Comment #2 on issue 7701 by [email protected]: Chromium: Crash Report -
Stack Signature: iat_patch::GetIATFunction
http://code.google.com/p/chromium/issues/detail?id=7701
Guessing from the command line, this is a plugin process.
CommandLine: '"c:\chrome-win32\chrome.exe" --noerrdialogs
--full-memory-crash-
report --enable-logging --user-data-dir=c:\chrome-win32\test_user_data
--enable-
dcheck --lang=en-US
--plugin-data-dir=c:\chrome-win32\test_user_data\Default --
type=plugin --channel=1540.331eae0.986721799 --plugin-path="C:\Program
Files\Mozilla
Firefox\plugins\NPSWF32.dll"'
Looking at the code:
// If a plugin is running in its own process it will get unloaded on
process
// shutdown.
if ((instance_count_ == 0) &&
webkit_glue::IsPluginRunningInRendererProcess()) {
Unload();
It seems we the code will never unload the native library. However, flash
has
clearly been unloaded:
Unloaded modules:
30000000 30395000 NPSWF32.dll
Ok, so, after some digging (but still not understanding the code 100%), my
guess
would be:
void PluginThread::CleanUp() {
[ ... ]
NPAPI::PluginLib::UnloadAllPlugins();
ChromePluginLib::UnloadAllPlugins();
(or possibly some other shutdown code calling UnloadAllPlugins).
UnloadAllPlugins calls Unload() directly, without doing the same
renderer/plugin
process checks. This means the unpatch code in webplugin_delegate_impl
DestroyInstance is not called, and the unpatch never occurs. We then try
to unpatch
at shutdown, after we have already unloaded the dll.
So, an overview of the timeline:
- WebPluginDelegateImpl::Initialize
- First instance of a given plugin, patch SetCursor and TrackPopupMenu
- Plugin is loaded, web page is loaded, etc
- The plugin is not destroyed normally by the page.
- The browser shuts down with a living plugin instance.
- The plugin thread tears down and UnloadAllPlugin()s, the iat patch is
still
"patched", but the underlying dll has been unloaded.
- AtExitManager teardown runs, we crash trying to unpatch a non-present dll.
The reason we see this periodically is that it is probably a race.
Normally we will
go down the cleaner shutdown path in which the plugin is destroyed by the
page and
unpatch when the last instance is cleanly torn down. There is probably
some timeout
we hit where we teardown the browser without tearing down the page /
plugin, in which
this race happens.
I believe the fix here lies in the plugin code (not the IAT patcher code),
and
probably needs to be done by John or Ananta. Assigning to Ananta who wrote
the
original code. Adding John.
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
--~--~---------~--~----~------------~-------~--~----~
Automated mail from issue updates at http://crbug.com/
Subscription options: http://groups.google.com/group/chromium-bugs
-~----------~----~----~----~------~----~------~--~---
