Bumping Pri

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

commit 9de6f24edfb54f9afd3d2dee474a2602585f68dc
Author: pwnall <pwnall@chromium.org>
Date: Sat Mar 25 01:12:03 2017

Ensure correctness for interleaved IndexedDB cursor iteration.

BUG= 702787 

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

[modify] https://crrev.com/9de6f24edfb54f9afd3d2dee474a2602585f68dc/content/shell/browser/layout_test/layout_test_content_browser_client.cc
[add] https://crrev.com/9de6f24edfb54f9afd3d2dee474a2602585f68dc/third_party/WebKit/LayoutTests/external/wpt/IndexedDB/interleaved-cursors.html
[modify] https://crrev.com/9de6f24edfb54f9afd3d2dee474a2602585f68dc/third_party/WebKit/LayoutTests/external/wpt/IndexedDB/support-promises.js

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

commit ec764054b12a8e21e1fe958c3f1e4d47df671066
Author: dmurph <dmurph@chromium.org>
Date: Mon Mar 27 23:12:47 2017

[IndexedDB] Pool and evict leveldb iterators, to save memory

Caps the total number of open cursors per database. Ideally the cap
would be on the # of bytes held by the cursors, but this data is deeply
hidden, and this is good enough for an initial mitigation.

Note: This could potentially cause worse memory churn if the number of
cursors allowed is too low.

R=jsbell,pwnall,cmumford
BUG= 696055 , 702787 

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

[modify] https://crrev.com/ec764054b12a8e21e1fe958c3f1e4d47df671066/content/browser/BUILD.gn
[modify] https://crrev.com/ec764054b12a8e21e1fe958c3f1e4d47df671066/content/browser/indexed_db/indexed_db_backing_store.cc
[modify] https://crrev.com/ec764054b12a8e21e1fe958c3f1e4d47df671066/content/browser/indexed_db/indexed_db_backing_store_unittest.cc
[modify] https://crrev.com/ec764054b12a8e21e1fe958c3f1e4d47df671066/content/browser/indexed_db/indexed_db_class_factory.cc
[modify] https://crrev.com/ec764054b12a8e21e1fe958c3f1e4d47df671066/content/browser/indexed_db/indexed_db_class_factory.h
[modify] https://crrev.com/ec764054b12a8e21e1fe958c3f1e4d47df671066/content/browser/indexed_db/indexed_db_cleanup_on_io_error_unittest.cc
[modify] https://crrev.com/ec764054b12a8e21e1fe958c3f1e4d47df671066/content/browser/indexed_db/leveldb/leveldb_database.cc
[modify] https://crrev.com/ec764054b12a8e21e1fe958c3f1e4d47df671066/content/browser/indexed_db/leveldb/leveldb_database.h
[add] https://crrev.com/ec764054b12a8e21e1fe958c3f1e4d47df671066/content/browser/indexed_db/leveldb/leveldb_iterator.cc
[modify] https://crrev.com/ec764054b12a8e21e1fe958c3f1e4d47df671066/content/browser/indexed_db/leveldb/leveldb_iterator.h
[modify] https://crrev.com/ec764054b12a8e21e1fe958c3f1e4d47df671066/content/browser/indexed_db/leveldb/leveldb_iterator_impl.cc
[modify] https://crrev.com/ec764054b12a8e21e1fe958c3f1e4d47df671066/content/browser/indexed_db/leveldb/leveldb_iterator_impl.h
[modify] https://crrev.com/ec764054b12a8e21e1fe958c3f1e4d47df671066/content/browser/indexed_db/leveldb/leveldb_transaction.cc
[modify] https://crrev.com/ec764054b12a8e21e1fe958c3f1e4d47df671066/content/browser/indexed_db/leveldb/leveldb_transaction.h
[modify] https://crrev.com/ec764054b12a8e21e1fe958c3f1e4d47df671066/content/browser/indexed_db/leveldb/leveldb_transaction_unittest.cc
[modify] https://crrev.com/ec764054b12a8e21e1fe958c3f1e4d47df671066/content/browser/indexed_db/leveldb/leveldb_unittest.cc
[modify] https://crrev.com/ec764054b12a8e21e1fe958c3f1e4d47df671066/content/browser/indexed_db/mock_browsertest_indexed_db_class_factory.cc
[modify] https://crrev.com/ec764054b12a8e21e1fe958c3f1e4d47df671066/content/browser/indexed_db/mock_browsertest_indexed_db_class_factory.h

It looks like crash numbers are way down since the Docs mitigation push on Monday evening:

https://crash.corp.google.com/browse?q=OMIT%20RECORD%20IF%20SUM%28CrashedStackTrace.StackFrame.FunctionName%3D%27content%3A%3AIndexedDBDatabase%3A%3AOpenCursorOperation%28std%3A%3Aunique_ptr%3Ccontent%3A%3AIndexedDBDatabase%3A%3AOpenCursorOperationParams%2Cstd%3A%3Adefault_delete%3Ccontent%3A%3AIndexedDBDatabase%3A%3AOpenCursorOperationParams%3E%20%3E%2Ccontent%3A%3AIndexedDBTransaction%20*%29%27%29%20%3D%200&ignore_case=false&enable_rewrite=true&omit_field_name=CrashedStackTrace.StackFrame.FunctionName&omit_field_value=content%3A%3AIndexedDBDatabase%3A%3AOpenCursorOperation%28std%3A%3Aunique_ptr%3Ccontent%3A%3AIndexedDBDatabase%3A%3AOpenCursorOperationParams%2Cstd%3A%3Adefault_delete%3Ccontent%3A%3AIndexedDBDatabase%3A%3AOpenCursorOperationParams%3E%20%3E%2Ccontent%3A%3AIndexedDBTransaction%20*%29&omit_field_opt=%3D#samplereports:5,day:30

I'm going to switch this to Fixed (also because of our own patch above), and start on a postmortem.

For clarification, push was on 2017/03/27 at 8pm, and the percent went from 0.58% on Monday to 0.16% on Tuesday.

Do we need to merge this back to older versions ?
I know we addressed the drive offline issue, but we may need to worry about other apps as well which may hit it.

#7: I would prefer not to merge this, unless the crash rate goes back up. While the fix CL is much smaller than I could have hoped for (props to dmurph@!), it still changes our performance profile in a non-trivial way, so it'd be nice to have it bake through the normal channel progression.

I agree - I think it's safer to let the bake, and the crash reports are pretty low (I think?) - around 200 or less every day.

(some of which are probably legitimate OOM). Previously w/ docs hitting this the crash rate was in the mid thousands.

Also, keep in mind that the CL above wouldn't fix all the IndexedDB OOM crashes. That crash stack points to a site where we allocate (comparatively) larger blocks of memory, so an OOM is more likely to hit there than in most other callsites for memory allocators.