diff options
author | ananta@chromium.org <ananta@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-02-11 00:39:37 +0000 |
---|---|---|
committer | ananta@chromium.org <ananta@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-02-11 00:39:37 +0000 |
commit | 0815b6de5c6a8f079d149067d265c6bf0c5c2604 (patch) | |
tree | 5ece70212c9e0f06d626e49db4279a306fafa2ee /base | |
parent | 7358c577f90107138af8d96035d687556e4570b3 (diff) | |
download | chromium_src-0815b6de5c6a8f079d149067d265c6bf0c5c2604.zip chromium_src-0815b6de5c6a8f079d149067d265c6bf0c5c2604.tar.gz chromium_src-0815b6de5c6a8f079d149067d265c6bf0c5c2604.tar.bz2 |
Maintain a refcounted AutomationProvider pointer in the ExternalTabContainer. This ensures that we don't crash the browser while trying to dereference a freed AutomationProvider pointer.
When a Chrome browser instance starts up, we attempt to locate an already running instance and defer to it to complete the navigation request. However it is quite possible for the running instance to exit while we attempt to send a WM_COPYDATA message to it. This caused a bunch
of ASSERTS to fire off in the browser.
Fixes as below:-
1. If GetWindowThreadProcessId fails, we bail out and try to launch a new chrome instance
2. If SendMessageTimeout fails, we check if the window is still valid. If not we bail out and try to launch a new chrome instance.
3. We return an error from the WM_COPYDATA handler if the chrome instance is in the process of shutting down. We handle this at the caller end, i.e. in NotifyOtherProcess.
Bug=1643310
Review URL: http://codereview.chromium.org/23016
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9536 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'base')
0 files changed, 0 insertions, 0 deletions