I don't repro. Can you attach a crash report ID?
Sergio, could you have a look?

Annnd… reproed. Crash ID: https://crash.corp.google.com/browse?stbtiq=13897efd90000000

-[HistoryCollectionViewController historyServiceFacade:didReceiveQueryResult:]

We might reopen issue 707241 then.

The problem is not on trunk. I can't repro on a recent local build.
Can we check branch M58 to make sure that cherrypick happened correctly?

The crash with signature -[HistoryCollectionViewController historyServiceFacade:didReceiveQueryResult:] was only reproducible on M57 before M58 went to the public. So you might not be able to see it on trunk.

Should this be duped against issue 707241 or should we keep this tracker open as well?

Users experienced this crash on the following builds:

Ios Beta 58.0.3029.82 -  133.73 CPM, 5 reports, 5 clients (signature -[HistoryCollectionViewController historyServiceFacade:didReceiveQueryResult:])

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas

Good Version 58.0.3029.64 #f53c1c3
Bad Version 58.0.3029.65 #8b4fbd3

This issue is also reproduced on M60.0.3083.0 canary.

Also note from shbarezer@, This issue is only reproduced If the user is signed into Chrome. If the user is not signed into Chrome, the searching through History works fine.

Note: This issue appears only with account with no passphrase, Account with Passphrase works fine

Link to the Video:
https://drive.google.com/a/google.com/file/d/0BwSBFDzHIX-mMzh6WE9OMEhQMmc/view

Users experienced this crash on the following builds:

Ios Beta 59.0.3071.27 -  247.77 CPM, 1 reports, 1 clients (signature -[HistoryCollectionViewController historyServiceFacade:didReceiveQueryResult:])

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas

Users experienced this crash on the following builds:

Ios Dev 60.0.3080.0 -  253.23 CPM, 5 reports, 2 clients (signature -[HistoryCollectionViewController historyServiceFacade:didReceiveQueryResult:])

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas

 Issue 716928  has been merged into this issue.

ccing: ramyasharma 

Using the same completion blocker for updating and deleting as I proposed on https://codereview.chromium.org/2800473004/ increased the crash rate under these circumstances (No passphrase and signed in). I'm also not sure if the passphrase related fixes we made had some effect on this, though I doubt it. 

If the crash ratio is getting pretty bad I guess we can revert https://codereview.chromium.org/2800473004/, but I will still take a look at a new fix now that we have more information.

 Issue 717185  has been merged into this issue.

Just as an FYI: Some changes were made to the sync_service in the same time as well, though after some testing I highly doubt these are related: 
https://codereview.chromium.org/2790483002

I've created a revert for this issue and I'm still looking at the root cause:
https://codereview.chromium.org/2855883002/

Crash ID : a97618c350000000
please let me know if I can get any other info from the device.

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

commit 4575e0c18c3fea30e4f59ccc4c00fca6e6014698
Author: sczs <sczs@chromium.org>
Date: Wed May 03 01:21:21 2017

[ios] Revert of History didReceiveQueryResult performBatchUpdates.

This reverts: https://codereview.chromium.org/2800473004/
Since it increased the crash rate as in  bug 716349 .

BUG= 716349 

Review-Url: https://codereview.chromium.org/2855883002
Cr-Commit-Position: refs/heads/master@{#468856}

[modify] https://crrev.com/4575e0c18c3fea30e4f59ccc4c00fca6e6014698/ios/chrome/browser/ui/history/history_collection_view_controller.mm

I've committed the revert and I'm still looking into the root cause. 

Using the same performBatchUpdates block made the crash more apparent since sync can add items to the model (that weren't there on the first place) while filtering, thats why when we delete something the model complains about inconsistency. 

I have more idea of what's going on and right now I don't think the root cause fix will be trivial, so I still think we should revert first. Especially after the high number of crashes this is causing. 

Will mark this as Fixed in order to cherry pick into M-58 and M-59

This bug requires manual review: Reverts referenced in bugdroid comments after merge request.
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), gkihumba@(ChromeOS), Abdul Syed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Can this be tested in M60 to make sure we are back to what we used to be before  and searching on history does not consistently crash the app anymore?

App crashes on performing search in history.
Retested the issue on 59.0.3071.30 beta and 60.0.3088.0 canary tested on iPhone5(iOS 9.3.5).

App is still crashing as of 60.0.3088.0 build. We will wait till next canary and try to verify in there.

Looks good on M60.0.3089.0 canary
No crashes when searching History.
Verified on iPhone7, iPad Pro.
iOS: 10.3.2, 10.1.1

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

commit ec201b43f4c8b52349267a54f249b846eab72db2
Author: sczs <sczs@chromium.org>
Date: Thu May 04 17:44:28 2017

[ios] Revert of History didReceiveQueryResult performBatchUpdates.

This reverts: https://codereview.chromium.org/2800473004/
Since it increased the crash rate as in  bug 716349 .

BUG= 716349 

Review-Url: https://codereview.chromium.org/2855883002
Cr-Commit-Position: refs/heads/master@{#468856}
(cherry picked from commit 4575e0c18c3fea30e4f59ccc4c00fca6e6014698)

Review-Url: https://codereview.chromium.org/2862653003 .
Cr-Commit-Position: refs/branch-heads/3029@{#796}
Cr-Branched-From: 939b32ee5ba05c396eef3fd992822fcca9a2e262-refs/heads/master@{#454471}

[modify] https://crrev.com/ec201b43f4c8b52349267a54f249b846eab72db2/ios/chrome/browser/ui/history/history_collection_view_controller.mm

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

commit c380e4fa56ed29a200ff6fcdf34a67e4477cd3d6
Author: sczs <sczs@chromium.org>
Date: Thu May 04 17:59:45 2017

[ios] Revert of History didReceiveQueryResult performBatchUpdates.

This reverts: https://codereview.chromium.org/2800473004/
Since it increased the crash rate as in  bug 716349 .

BUG= 716349 

Review-Url: https://codereview.chromium.org/2855883002
Cr-Commit-Position: refs/heads/master@{#468856}
(cherry picked from commit 4575e0c18c3fea30e4f59ccc4c00fca6e6014698)

Review-Url: https://codereview.chromium.org/2860893005 .
Cr-Commit-Position: refs/branch-heads/3071@{#405}
Cr-Branched-From: a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641}

[modify] https://crrev.com/c380e4fa56ed29a200ff6fcdf34a67e4477cd3d6/ios/chrome/browser/ui/history/history_collection_view_controller.mm

Issue 718115 has been merged into this issue.

Sergio, is it possible to an EG test to prevent this type of regression?

 Issue 719184  has been merged into this issue.

Verified in 59.0.3071.50 beta, iPhone 6 plus iOS 10.2.1, iPad mini 10.3 beta 7

No crashes when searching History.

Verified the issue on the build 58.0.3029.113 dev tested on iPhone7+(iOS 10.3.1).
App doesn't crashes on performing search in history

 Issue 721683  has been merged into this issue.

Hi Sergio,
Have you already started a postmortem for this?
Thanks,

Hi Lindsay,

I'll start working in one, and will look into creating an eg test as Eugene suggested.

The issue is still happening for a small number of users: 

https://crash.corp.google.com/browse?q=product.name%3D%27Chrome_iOS%27%20AND%20product.Version%3D%2758.0.3029.113%27%20AND%20custom_data.ChromeCrashProto.magic_signature_1.name%3D%27-%5BHistoryCollectionViewController%20historyServiceFacade%3AdidReceiveQueryResult%3A%5D%27&ignore_case=false&enable_rewrite=false&omit_field_name=&omit_field_value=&omit_field_opt=#-property-selector,samplereports:5,productversion,device,background,recovery

Apparently is not happening that much, but will give users some time to update to the M58 re-spin.

Hi Sergio,
Any news on the postmortem?
Thanks,

Hi Lindsay!

Yes, I'm just waiting too se if someone else wants to add something to it, if not I think I'll share today. PTAL here: go/chromepostmortem449

Thank you!