cros: Fix crash when clicking on discarded tab

cros: Fix crash when clicking on discarded tab

In out of memory conditions Chrome OS R19 will "discard" tabs that have not been recently used.  The page is reloaded when the user selects the tab in the tab strip.  We're seeing occasional crashes in the field in the tab reload code due to null site instance pointers in the navigation controller.  This might have been caused by crrev.com/120007 which added the use of site instance.  I have no in-house repro for this crash but I have a user who can trigger it reliably -- we'll see if this patch helps her.

BUG=119068
TEST=crash reports should go down

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=129940

[James Cook, 2012-03-28 20:13:10]

Sky, PTAL.  Looking at http://codereview.chromium.org/9169065 the code used to
tolerate null site-instance pointers, but now assumes they are present.  This
change makes the code behave as it did before that change when there is no site
instance.

CC nasko - just FYI

[sky, 2012-03-28 20:38:39]

Generally when we're trying to identify a crash we'll add a CHECK to verify that
is in fact what is happening. We might also add CHECKs at various other points
that can help narrow down how we end in a particular state too.

[James Cook, 2012-03-28 20:56:10]

On 2012/03/28 20:38:39, sky wrote:
> Generally when we're trying to identify a crash we'll add a CHECK to verify
that
> is in fact what is happening. We might also add CHECKs at various other points
> that can help narrow down how we end in a particular state too.

Based on my read of the code there are multiple paths that can lead to NULL site
instances, so I'm suspicious that this is just a bug in this function.  I don't
think the error is that site instance is NULL when it shouldn't be.

For example, crash 97ebb61f0a72fad4 is a Chrome 19 crash on Windows with a NULL
site instance pointer, and Windows doesn't run the tab discard code.

Are you saying that site_instance shouldn't be NULL here and I should try to
figure out why it is?

[sky, 2012-03-28 21:50:26]

I'm not sure. I'm adding Charlie to the review list, who knows about
SiteInstance.

[James Cook, 2012-03-28 22:22:21]

On 2012/03/28 21:50:26, sky wrote:
> I'm not sure. I'm adding Charlie to the review list, who knows about
> SiteInstance.

I also see several other places in the code that explicitly check for NULL
entry->site_instance(), such as in TabContents::OnGoToEntryAtOffset(),
RenderViewHostManager::GetSiteInstanceForEntry(), and
NavigationControllerImpl::NavigateToPendingEntry().  But perhaps it should be
non-NULL during a reload?  I do see mentions that NULL site instances are
associated with session restore.

[(Do not use) nasko, 2012-03-29 15:14:03]

On Wed, Mar 28, 2012 at 3:22 PM, <[email protected]> wrote:

> On 2012/03/28 21:50:26, sky wrote:
>
>> I'm not sure. I'm adding Charlie to the review list, who knows about
>> SiteInstance.
>>
>
> I also see several other places in the code that explicitly check for NULL
> entry->site_instance(), such as in TabContents::**OnGoToEntryAtOffset(),
> RenderViewHostManager::**GetSiteInstanceForEntry(), and
> NavigationControllerImpl::**NavigateToPendingEntry().  But perhaps it
> should be
> non-NULL during a reload?  I do see mentions that NULL site instances are
> associated with session restore.
>
>
I'll let Charlie be the authoritative source, but when we are reloading a
page, it should already have a site instance associated with. I had that
same check for NULL, but the discussion was that this shouldn't be the
case. Session restore on the other hand should not be a reload, though it
is a good thing to confirm/deny.
Thanks,
Nasko

[James Cook, 2012-03-29 15:34:42]

On 2012/03/29 15:14:03, nasko_google.com wrote:
> On Wed, Mar 28, 2012 at 3:22 PM, <mailto:[email protected]> wrote:
> 
> > On 2012/03/28 21:50:26, sky wrote:
> >
> >> I'm not sure. I'm adding Charlie to the review list, who knows about
> >> SiteInstance.
> >>
> >
> > I also see several other places in the code that explicitly check for NULL
> > entry->site_instance(), such as in TabContents::**OnGoToEntryAtOffset(),
> > RenderViewHostManager::**GetSiteInstanceForEntry(), and
> > NavigationControllerImpl::**NavigateToPendingEntry().  But perhaps it
> > should be
> > non-NULL during a reload?  I do see mentions that NULL site instances are
> > associated with session restore.
> >
> >
> I'll let Charlie be the authoritative source, but when we are reloading a
> page, it should already have a site instance associated with. I had that
> same check for NULL, but the discussion was that this shouldn't be the
> case. Session restore on the other hand should not be a reload, though it
> is a good thing to confirm/deny.
> Thanks,
> Nasko

OK, it sounds like a NULL site_instance is creeping in where it shouldn't be. 
I'll add some CHECK() calls in another patch to see if I can find where.

[Charlie Reis, 2012-03-30 17:14:02]

I think the real issue here is that both the DiscardTab case and some other case
(as demonstrated by the Windows crash) are getting to Reload with a null
SiteInstance.

However, while we revise DiscardTab and track down the Windows bug, I'm ok with
adding the null check to avoid a hard crash in the field.  It will behave
properly in the meantime, since the HasWrongProcessForURL logic only matters if
we do have a SiteInstance.

LGTM.

http://codereview.chromium.org/9802047/diff/1/content/browser/tab_contents/na...
File content/browser/tab_contents/navigation_controller_impl.cc (left):

http://codereview.chromium.org/9802047/diff/1/content/browser/tab_contents/na...
content/browser/tab_contents/navigation_controller_impl.cc:277:
DCHECK(site_instance);
Let's add the null check below to avoid a crash in the field, but keep this
DCHECK to help us track down the bug on Windows.

[commit-bot: I haz the power, 2012-03-30 17:24:05]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/9802047/8001

[commit-bot: I haz the power, 2012-03-30 17:24:08]

Presubmit check for 9802047-8001 failed and returned exit status 1.

Running presubmit commit checks ...

** Presubmit ERRORS **
Missing LGTM from an OWNER for files in these directories:
    content/browser

[James Cook, 2012-03-30 17:25:13]

Scott, I need OWNERs approval.

[sky, 2012-03-30 18:09:15]

LGTM

[commit-bot: I haz the power, 2012-03-30 18:10:56]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/9802047/8001