P1 since it's a crash

Assigning to Justin. If you don't have time to look at it before being OOO, please assign back to me.

Exception is:
"Invalid update: invalid number of items in section 3. The number of items contained in an existing section after the update (1) must be equal to the number of items contained in that section before the update (0), plus or minus the number of items inserted or deleted from that section (0 inserted, 0 deleted) and plus or minus the number of items moved into or out of that section (0 moved in, 0 moved out)."

gambard@ I'm unable to reproduce this.  Any ideas?

I was able to reproduce. Doing a cold start with the suggestions hidden prevent the ContentSuggestionsProvider from starting. So when the provider is up, it is notifying the NTP that new suggestions are available. This triggers a change in the CollectionView, which adds the newly available items. At the end of this animation, we are checking if the section is empty, and if it is an empty item is added.
If you press hide during this animation, then you remove all items. So the empty item is added but I guess there is a problem with it? I don't really know what is happening but I think it has to do with that.

gambard@ can you take a look while I'm OOO?  Thanks!

I have easier reproduction step:
1. Hide the articles
2. Restart the app
3. Tap "show" then "hide" quickly
4. Wait 2-3s
5. Tap "show"

The crash is caused by the "Learn More" section being added while only the "Articles" section is being reloaded.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/49983345b0047ab314b55876cc0032bb063d9ef8

commit 49983345b0047ab314b55876cc0032bb063d9ef8
Author: Gauthier Ambard <gambard@chromium.org>
Date: Tue Jul 31 15:46:23 2018

Fix section reload in NTP

When a ContentSuggestions section is reloaded in the NTP, it is possible
that new sections/items in other sections are added.
This CL makes sure that the collection is updated to take those new
elements into account.

Bug:  866849 
Cq-Include-Trybots: luci.chromium.try:ios-simulator-full-configs;master.tryserver.chromium.mac:ios-simulator-cronet
Change-Id: Id474ca33afdafb18871b2bb77e4a94e8bfe1cc68
Reviewed-on: https://chromium-review.googlesource.com/1154986
Commit-Queue: Gauthier Ambard <gambard@chromium.org>
Reviewed-by: Stepan Khapugin <stkhapugin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#579416}
[modify] https://crrev.com/49983345b0047ab314b55876cc0032bb063d9ef8/ios/chrome/browser/ui/content_suggestions/content_suggestions_collection_updater.mm
[modify] https://crrev.com/49983345b0047ab314b55876cc0032bb063d9ef8/ios/chrome/browser/ui/content_suggestions/content_suggestions_egtest.mm

Verified on Canary.
+kariahda@ for merge approval.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/77d6650f234228e8b666c00f9564cccf21327bb3

commit 77d6650f234228e8b666c00f9564cccf21327bb3
Author: Gauthier Ambard <gambard@chromium.org>
Date: Wed Aug 01 14:28:00 2018

Fix section reload in NTP

When a ContentSuggestions section is reloaded in the NTP, it is possible
that new sections/items in other sections are added.
This CL makes sure that the collection is updated to take those new
elements into account.

Bug:  866849 
Cq-Include-Trybots: luci.chromium.try:ios-simulator-full-configs;master.tryserver.chromium.mac:ios-simulator-cronet
Change-Id: Id474ca33afdafb18871b2bb77e4a94e8bfe1cc68
Reviewed-on: https://chromium-review.googlesource.com/1154986
Commit-Queue: Gauthier Ambard <gambard@chromium.org>
Reviewed-by: Stepan Khapugin <stkhapugin@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#579416}(cherry picked from commit 49983345b0047ab314b55876cc0032bb063d9ef8)
Reviewed-on: https://chromium-review.googlesource.com/1158744
Reviewed-by: Gauthier Ambard <gambard@chromium.org>
Cr-Commit-Position: refs/branch-heads/3497@{#311}
Cr-Branched-From: 271eaf50594eb818c9295dc78d364aea18c82ea8-refs/heads/master@{#576753}
[modify] https://crrev.com/77d6650f234228e8b666c00f9564cccf21327bb3/ios/chrome/browser/ui/content_suggestions/content_suggestions_collection_updater.mm
[modify] https://crrev.com/77d6650f234228e8b666c00f9564cccf21327bb3/ios/chrome/browser/ui/content_suggestions/content_suggestions_egtest.mm

Verified in:

App Version: 70.0.3515.0 canary
Devices: iPhone 7 Plus, iPhone 8 Plus, iPad Air
iOS Versions: 10.3.3, 11.4.1, 12.0 beta 6

Crash is not reproducible following the steps mentioned in Comment#0 & #6.

Issue verified 
Version: Chrome Beta 69.0.3497.31
Device: iPhone 8
iOS: 11.4

There is no crash on tapping show/hide multiple times
https://drive.google.com/open?id=1-WDMW4ZKEJVjLJi7zenpsU_qSI4S2ue5

We have the same crash report on chrome beta version on 69.0.3497.41 
https://crash.corp.google.com/browse?stbtiq=73973e000ef03f3b

Rechecked and could not reproduce the crash following the steps mentioned in comment #6 on latest chrome beta version 69.0.3497.58.

Will keep monitoring the crash reports.

Seeing quite a few of these in M69 1% rollout. This is making up 5% of all crashes (1950 reports).

The stack trace looks the same. The exceptionReason is:

*** -[NSIndexSet initWithIndexesInRange:]: Range {9223372036854775807, 1} exceeds maximum index value of NSNotFound - 1

Seems like sectionForSectionIdentifier:sectionIdentifier is returning NSNotFound (which would DCHECK in debug code, this shouldn't be possible).

We could add an extra return to be safe, but this is not ideal.  Any idea how to reproduce?

diff --git a/ios/chrome/browser/ui/content_suggestions/content_suggestions_collection_updater.mm b/ios/chrome/browser/ui/content_suggestions/content_suggestions_collection_updater.mm
index d5aae12c8f3c..d1a05b9e8639 100644
--- a/ios/chrome/browser/ui/content_suggestions/content_suggestions_collection_updater.mm
+++ b/ios/chrome/browser/ui/content_suggestions/content_suggestions_collection_updater.mm
@@ -367,7 +367,8 @@ NSString* const kContentSuggestionsCollectionUpdaterSnackbarCategory =

   // Make sure we get the right index for the section.
   section = [model sectionForSectionIdentifier:sectionIdentifier];
-
+  if (section == NSNotFound)
+    return;
   [self.collectionViewController.collectionView
       reloadSections:[NSIndexSet indexSetWithIndex:section]];
 }

I pinged test team to try and repro with above steps or new ones.

Verified on 70.0.3538.6 Beta, iPhone 7 iOS 12.0 beta#12, 

Crash is not reproducible following the steps mentioned in Comment#0 & #6.

Hi
I'm seeing 19 AW Snap crashes since yesterday
https://screenshot.googleplex.com/424EC5dKFOX

Examples
https://listnr.corp.google.com/product/5031434/report/85641601282
https://listnr.corp.google.com/product/5031434/report/85641297715
https://listnr.corp.google.com/product/5031434/report/85640059272
https://listnr.corp.google.com/product/5031434/report/85639804639


I see across both iPad and iPhone on iOS 11.4.1, Chrome 69.0.3497.71, across different locales.

We should really see about a fix for this. According to "gUP Chrome M69 Day 1 Launch Report" this is the top iOS trending issue.

This is currently assigned to someone who is OOO until the middle of next week.

I don't know if anyone in MTV is still around to investigate tonight.  I'll assign it to marq to see if anyone in Paris can pick this up in the morning, and I'll CC kkhorimoto in case he's still around tonight.  Justin and I can pick it back up in the morning.

It sounds like this is now for M69?

The Aw Snap reports from #21 are likely unrelated, because this bug is for a full browser crash, not renderer crashes.

If we're seeing an uptick in Aw Snap reports, we should split that off into a new bug and investigate.

The prominent M69 crash is not this bug. This bug is for hammering show/hide, and the stack trace's relevant parts are:

 -[ContentSuggestionsCollectionUpdater reloadSection:]
 -[ContentSuggestionsMediator toggleArticlesVisibility]

The M69 crash is:

 -[ContentSuggestionsCollectionUpdater reloadSection:]
 -[ContentSuggestionsMediator useFreshMostVisited]
 -[NTPHomeMediator removeMostVisited:]

That is, deleting Most Visited items. 

This bug should probably be closed; I'll open a new bug to track the Most Visited issue.

Most Visited crash is crbug.com/881229

Note that the crash in #16 is also Most Visted, not hide/show.

Per crbug.com/881229, flipping this back to verified.