diff options
| author | sreeram@chromium.org <sreeram@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2012-10-29 23:08:50 +0000 |
|---|---|---|
| committer | sreeram@chromium.org <sreeram@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2012-10-29 23:08:50 +0000 |
| commit | e0e8fac17ff416ac0ff4e5bd11ed086b9cf52a44 (patch) | |
| tree | 133f58a0af2479b1e0f1db1d0f33757f5a69566c /sync | |
| parent | 855c276ad8226f34efbcbea8e7153dceff1c6889 (diff) | |
| download | chromium_src-e0e8fac17ff416ac0ff4e5bd11ed086b9cf52a44.zip chromium_src-e0e8fac17ff416ac0ff4e5bd11ed086b9cf52a44.tar.gz chromium_src-e0e8fac17ff416ac0ff4e5bd11ed086b9cf52a44.tar.bz2 | |
Possible fix for crash in InstantUnloadHandler::Destroy.
See bug report for crash details. My guess is that something leads to
the following sequence of events:
1. CloseContents() is called on the web contents delegate.
2. The delegate is removed from the delegates_ vector. The actual
delegate object is scheduled to be destroyed later (DeleteSoon).
3. Before the scheduled deletion occurs, CloseContents() is called
again. Since the vector doesn't have the pointer, the weak_erase()
fails. In debug mode, the DCHECK() would've caught this.
Fix by removing the delegate association in step 1. Note that the
delegate still hangs on the the TabContents. When the scheduled deletion
of the delegate happens, the TabContents will also be destroyed.
BUG=155848
R=sky@chromium.org
TEST=Watch crash reports. This shouldn't occur anymore.
Review URL: https://chromiumcodereview.appspot.com/11336019
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@164779 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'sync')
0 files changed, 0 insertions, 0 deletions