Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
266333002:
Add most of the metadata-handling code for blobs. It's not quite all there, but (Closed)
|
Created:
6 years, 7 months ago by ericu Modified:
6 years, 7 months ago CC:
chromium-reviews, jam, alecflett, ericu+idb_chromium.org, darin-cc_chromium.org, cmumford, dgrogan, jsbell+idb_chromium.org Base URL:
svn://svn.chromium.org/chrome/trunk/src Visibility:
Public. |
DescriptionAdd most of the metadata-handling code for blobs. It's not quite all there, but
this is the biggest chunk I can pull out vaguely cleanly. It does contain a
couple of fake calls to keep the compiler happy.
This CL also makes SetUpMetadata a member in order to ease testing in a later CL.
This depends on https://codereview.chromium.org/261843004/.
BUG=108012
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=270016
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=273048
Patch Set 1 #Patch Set 2 : Fix diffs #Patch Set 3 : Added back a removed function #Patch Set 4 : Coalesced fake calls #
Total comments: 6
Patch Set 5 : Rolled in Josh's feedback #
Total comments: 32
Patch Set 6 : Rolled in Chris's feedback and more from Josh. #Patch Set 7 : Fix merge error #Patch Set 8 : Release build fix. #Patch Set 9 : Merged out #Patch Set 10 : Rebased #Patch Set 11 : Remove PathExists check which we shouldn't now need. #Patch Set 12 : Added some logging. #Patch Set 13 : More debugging info. #Patch Set 14 : Yet still more debugging info. #Patch Set 15 : Even yet still more debugging info. #Patch Set 16 : Attempted fix. #Patch Set 17 : Remove debugging code; revert to approved version. #
Messages
Total messages: 34 (0 generated)
Not done, just initial notes https://codereview.chromium.org/266333002/diff/60001/content/browser/indexed_... File content/browser/indexed_db/indexed_db_backing_store.cc (right): https://codereview.chromium.org/266333002/diff/60001/content/browser/indexed_... content/browser/indexed_db/indexed_db_backing_store.cc:545: PutInt(leveldb_transaction, key, blob_key_generator_current_number); Must be PutVarInt to match DecodeVarInt above. https://codereview.chromium.org/266333002/diff/60001/content/browser/indexed_... content/browser/indexed_db/indexed_db_backing_store.cc:642: // Blob Data is encoded as { is_file [bool], key [int64 as varInt], Can you document that it's a series of these concatenated, with no length? (i.e. just keep decoding until there's no more data) https://codereview.chromium.org/266333002/diff/60001/content/browser/indexed_... File content/browser/indexed_db/indexed_db_backing_store.h (right): https://codereview.chromium.org/266333002/diff/60001/content/browser/indexed_... content/browser/indexed_db/indexed_db_backing_store.h:326: IndexedDBBackingStore* backing_store_; We should probably update the ownership graph soon: https://docs.google.com/a/chromium.org/drawings/d/1JBGlUYkJMJKT5KyIz0h34RxRIl...
https://codereview.chromium.org/266333002/diff/60001/content/browser/indexed_... File content/browser/indexed_db/indexed_db_backing_store.cc (right): https://codereview.chromium.org/266333002/diff/60001/content/browser/indexed_... content/browser/indexed_db/indexed_db_backing_store.cc:545: PutInt(leveldb_transaction, key, blob_key_generator_current_number); On 2014/05/06 00:24:16, jsbell wrote: > Must be PutVarInt to match DecodeVarInt above. Ouch! Fixed. https://codereview.chromium.org/266333002/diff/60001/content/browser/indexed_... content/browser/indexed_db/indexed_db_backing_store.cc:642: // Blob Data is encoded as { is_file [bool], key [int64 as varInt], On 2014/05/06 00:24:16, jsbell wrote: > Can you document that it's a series of these concatenated, with no length? > > (i.e. just keep decoding until there's no more data) Done. https://codereview.chromium.org/266333002/diff/60001/content/browser/indexed_... File content/browser/indexed_db/indexed_db_backing_store.h (right): https://codereview.chromium.org/266333002/diff/60001/content/browser/indexed_... content/browser/indexed_db/indexed_db_backing_store.h:326: IndexedDBBackingStore* backing_store_; On 2014/05/06 00:24:16, jsbell wrote: > We should probably update the ownership graph soon: > > https://docs.google.com/a/chromium.org/drawings/d/1JBGlUYkJMJKT5KyIz0h34RxRIl... Updated. There's nothing in the key about what colors mean, though, so they may need correction.
lgtm https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... File content/browser/indexed_db/indexed_db_backing_store.cc (right): https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... content/browser/indexed_db/indexed_db_backing_store.cc:661: EncodeVarInt(info.size(), &ret); Can you add '(var int') to the docs at the top of indexed_db_leveldb_coding.cc ? https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... content/browser/indexed_db/indexed_db_backing_store.cc:2516: else { Inconsistent bracing (if any if/else branch uses braces, all must)
On 2014/05/06 17:26:19, ericu wrote: > Updated. There's nothing in the key about what colors mean, though, so they may > need correction. Added a key. Recoloring grouped/layered things is a pain so I'm ignoring it for now.
https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... File content/browser/indexed_db/indexed_db_backing_store.cc (right): https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... content/browser/indexed_db/indexed_db_backing_store.cc:376: INTERNAL_WRITE_ERROR(SET_UP_METADATA); INTERNAL_READ_ERROR_UNTESTED https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... content/browser/indexed_db/indexed_db_backing_store.cc:420: INTERNAL_WRITE_ERROR(SET_UP_METADATA); INTERNAL_READ_ERROR_UNTESTED https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... content/browser/indexed_db/indexed_db_backing_store.cc:514: INTERNAL_READ_ERROR(GET_BLOB_KEY_GENERATOR_CURRENT_NUMBER); INTERNAL_READ_ERROR_UNTESTED https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... content/browser/indexed_db/indexed_db_backing_store.cc:521: INTERNAL_READ_ERROR(GET_BLOB_KEY_GENERATOR_CURRENT_NUMBER); INTERNAL_READ_ERROR_UNTESTED https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... content/browser/indexed_db/indexed_db_backing_store.cc:1061: !backing_store->CleanUpBlobJournal(LiveBlobJournalKey::Encode()).ok()) If SetupMetaData fails for whatever reason backing_store will be NULL. https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... content/browser/indexed_db/indexed_db_backing_store.cc:1062: return scoped_refptr<IndexedDBBackingStore>(); Do you want to record a histogram value here in case of failure? https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... content/browser/indexed_db/indexed_db_backing_store.cc:1228: INTERNAL_READ_ERROR(GET_IDBDATABASE_METADATA); _UNTESTED https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... content/browser/indexed_db/indexed_db_backing_store.cc:1236: INTERNAL_CONSISTENCY_ERROR(GET_IDBDATABASE_METADATA); _UNTESTED https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... content/browser/indexed_db/indexed_db_backing_store.cc:1342: for (it->Seek(start_key); Seek/Next/etc. now return Status objects. should check these. https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... content/browser/indexed_db/indexed_db_backing_store.cc:1349: INTERNAL_CONSISTENCY_ERROR(GET_IDBDATABASE_METADATA); _UNTESTED https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... content/browser/indexed_db/indexed_db_backing_store.cc:1367: return InternalInconsistencyStatus(); Why not return "s" here? https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... content/browser/indexed_db/indexed_db_backing_store.cc:1737: INTERNAL_CONSISTENCY_ERROR(DELETE_OBJECT_STORE); _UNTESTED https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... content/browser/indexed_db/indexed_db_backing_store.cc:2538: it->Seek(encoded_key); Status
On 2014/05/06 18:31:37, jsbell wrote: > On 2014/05/06 17:26:19, ericu wrote: > > Updated. There's nothing in the key about what colors mean, though, so they > may > > need correction. > > Added a key. Recoloring grouped/layered things is a pain so I'm ignoring it for > now. Recolored; I think I got everything.
https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... File content/browser/indexed_db/indexed_db_backing_store.cc (right): https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... content/browser/indexed_db/indexed_db_backing_store.cc:376: INTERNAL_WRITE_ERROR(SET_UP_METADATA); On 2014/05/06 18:33:11, cmumford wrote: > INTERNAL_READ_ERROR_UNTESTED INTERNAL_WRITE_ERROR_UNTESTED? Switched to that. https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... content/browser/indexed_db/indexed_db_backing_store.cc:420: INTERNAL_WRITE_ERROR(SET_UP_METADATA); On 2014/05/06 18:33:11, cmumford wrote: > INTERNAL_READ_ERROR_UNTESTED Same? https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... content/browser/indexed_db/indexed_db_backing_store.cc:514: INTERNAL_READ_ERROR(GET_BLOB_KEY_GENERATOR_CURRENT_NUMBER); On 2014/05/06 18:33:11, cmumford wrote: > INTERNAL_READ_ERROR_UNTESTED Done. https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... content/browser/indexed_db/indexed_db_backing_store.cc:521: INTERNAL_READ_ERROR(GET_BLOB_KEY_GENERATOR_CURRENT_NUMBER); On 2014/05/06 18:33:11, cmumford wrote: > INTERNAL_READ_ERROR_UNTESTED Done. https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... content/browser/indexed_db/indexed_db_backing_store.cc:661: EncodeVarInt(info.size(), &ret); On 2014/05/06 18:29:48, jsbell wrote: > Can you add '(var int') to the docs at the top of indexed_db_leveldb_coding.cc ? Done. That's the blob journal, not this blob data, though. Since this is done here, not in that file, it's not documented over there, only in the comment above this function. https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... content/browser/indexed_db/indexed_db_backing_store.cc:1061: !backing_store->CleanUpBlobJournal(LiveBlobJournalKey::Encode()).ok()) On 2014/05/06 18:33:11, cmumford wrote: > If SetupMetaData fails for whatever reason backing_store will be NULL. Fixed. https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... content/browser/indexed_db/indexed_db_backing_store.cc:1062: return scoped_refptr<IndexedDBBackingStore>(); On 2014/05/06 18:33:11, cmumford wrote: > Do you want to record a histogram value here in case of failure? Yeah, good idea. https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... content/browser/indexed_db/indexed_db_backing_store.cc:1228: INTERNAL_READ_ERROR(GET_IDBDATABASE_METADATA); On 2014/05/06 18:33:11, cmumford wrote: > _UNTESTED Done. https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... content/browser/indexed_db/indexed_db_backing_store.cc:1236: INTERNAL_CONSISTENCY_ERROR(GET_IDBDATABASE_METADATA); On 2014/05/06 18:33:11, cmumford wrote: > _UNTESTED Done. https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... content/browser/indexed_db/indexed_db_backing_store.cc:1342: for (it->Seek(start_key); On 2014/05/06 18:33:11, cmumford wrote: > Seek/Next/etc. now return Status objects. should check these. Working on that now. On the last step of an iterator, to where it runs off the end of the database, does it still return s.ok() even if !it->IsValid()? I'm crawling through the leveldb code, and it's not clear [and is AFAICT undocumented]. https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... content/browser/indexed_db/indexed_db_backing_store.cc:1349: INTERNAL_CONSISTENCY_ERROR(GET_IDBDATABASE_METADATA); On 2014/05/06 18:33:11, cmumford wrote: > _UNTESTED Done. https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... content/browser/indexed_db/indexed_db_backing_store.cc:1367: return InternalInconsistencyStatus(); On 2014/05/06 18:33:11, cmumford wrote: > Why not return "s" here? Done. https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... content/browser/indexed_db/indexed_db_backing_store.cc:1737: INTERNAL_CONSISTENCY_ERROR(DELETE_OBJECT_STORE); On 2014/05/06 18:33:11, cmumford wrote: > _UNTESTED Done. https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... content/browser/indexed_db/indexed_db_backing_store.cc:2516: else { On 2014/05/06 18:29:48, jsbell wrote: > Inconsistent bracing (if any if/else branch uses braces, all must) Done. https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... content/browser/indexed_db/indexed_db_backing_store.cc:2538: it->Seek(encoded_key); On 2014/05/06 18:33:11, cmumford wrote: > Status Done.
https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... File content/browser/indexed_db/indexed_db_backing_store.cc (right): https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... content/browser/indexed_db/indexed_db_backing_store.cc:420: INTERNAL_WRITE_ERROR(SET_UP_METADATA); On 2014/05/06 20:07:42, ericu wrote: > On 2014/05/06 18:33:11, cmumford wrote: > > INTERNAL_READ_ERROR_UNTESTED > > Same? Woops - my note was bad (READ vs. WRITE). But yes, we now only use the *_UNTESTED version of the macros everywhere _unless_ we have a unit test that hits that one line. https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... content/browser/indexed_db/indexed_db_backing_store.cc:1342: for (it->Seek(start_key); On 2014/05/06 20:07:42, ericu wrote: > On 2014/05/06 18:33:11, cmumford wrote: > > Seek/Next/etc. now return Status objects. should check these. > > Working on that now. On the last step of an iterator, to where it runs off the > end of the database, does it still return s.ok() even if !it->IsValid()? I'm > crawling through the leveldb code, and it's not clear [and is AFAICT > undocumented]. I believe that it will return OK() and the iterator will be !valid, but I'm not 100% on that. When I modified those routines to return status codes I left in the IsValid() checks and added OK() checks to them and all tests still pass (FWTW).
On 2014/05/06 20:41:47, cmumford wrote: > https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... > File content/browser/indexed_db/indexed_db_backing_store.cc (right): > > https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... > content/browser/indexed_db/indexed_db_backing_store.cc:420: > INTERNAL_WRITE_ERROR(SET_UP_METADATA); > On 2014/05/06 20:07:42, ericu wrote: > > On 2014/05/06 18:33:11, cmumford wrote: > > > INTERNAL_READ_ERROR_UNTESTED > > > > Same? > > Woops - my note was bad (READ vs. WRITE). But yes, we now only use the > *_UNTESTED version of the macros everywhere _unless_ we have a unit test that > hits that one line. > > https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... > content/browser/indexed_db/indexed_db_backing_store.cc:1342: for > (it->Seek(start_key); > On 2014/05/06 20:07:42, ericu wrote: > > On 2014/05/06 18:33:11, cmumford wrote: > > > Seek/Next/etc. now return Status objects. should check these. > > > > Working on that now. On the last step of an iterator, to where it runs off > the > > end of the database, does it still return s.ok() even if !it->IsValid()? I'm > > crawling through the leveldb code, and it's not clear [and is AFAICT > > undocumented]. > > I believe that it will return OK() and the iterator will be !valid, but I'm not > 100% on that. When I modified those routines to return status codes I left in > the IsValid() checks and added OK() checks to them and all tests still pass > (FWTW). Ah, I see. I just checked, and it looks like I'm using the same pattern as in e.g. GetDatabaseNames, so we should be either all correct or all wrong. My tests pass too, but I'm not absolutely sure I'm tickling all edge cases which could happen in the wild.
On 2014/05/06 20:48:42, ericu wrote: > On 2014/05/06 20:41:47, cmumford wrote: > > > https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... > > File content/browser/indexed_db/indexed_db_backing_store.cc (right): > > > > > https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... > > content/browser/indexed_db/indexed_db_backing_store.cc:420: > > INTERNAL_WRITE_ERROR(SET_UP_METADATA); > > On 2014/05/06 20:07:42, ericu wrote: > > > On 2014/05/06 18:33:11, cmumford wrote: > > > > INTERNAL_READ_ERROR_UNTESTED > > > > > > Same? > > > > Woops - my note was bad (READ vs. WRITE). But yes, we now only use the > > *_UNTESTED version of the macros everywhere _unless_ we have a unit test that > > hits that one line. > > > > > https://codereview.chromium.org/266333002/diff/80001/content/browser/indexed_... > > content/browser/indexed_db/indexed_db_backing_store.cc:1342: for > > (it->Seek(start_key); > > On 2014/05/06 20:07:42, ericu wrote: > > > On 2014/05/06 18:33:11, cmumford wrote: > > > > Seek/Next/etc. now return Status objects. should check these. > > > > > > Working on that now. On the last step of an iterator, to where it runs off > > the > > > end of the database, does it still return s.ok() even if !it->IsValid()? > I'm > > > crawling through the leveldb code, and it's not clear [and is AFAICT > > > undocumented]. > > > > I believe that it will return OK() and the iterator will be !valid, but I'm > not > > 100% on that. When I modified those routines to return status codes I left in > > the IsValid() checks and added OK() checks to them and all tests still pass > > (FWTW). > > Ah, I see. I just checked, and it looks like I'm using the same pattern as in > e.g. GetDatabaseNames, so we should be either all correct or all wrong. My > tests pass too, but I'm not absolutely sure I'm tickling all edge cases which > could happen in the wild. As mentioned in another thread, I'm going to try to add more test cases in another CL.
lgtm
The CQ bit was checked by ericu@chromium.org
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/ericu@chromium.org/266333002/100001
On 2014/05/09 16:34:57, I haz the power (commit-bot) wrote: > CQ is trying da patch. Follow status at > https://chromium-status.appspot.com/cq/ericu@chromium.org/266333002/100001 Once again, I clicked CQ forgetting that I had to wait for the other CL to land. Sorry about the build failure noise.
FYI, CQ is re-trying this CL (attempt #1). Please consider checking whether the failures are real, and report flakes to chrome-troopers@google.com. The failing builders are: android_aosp on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/android_aosp/builds/7...) android_chromium_gn_compile_rel on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/android_chromium_gn_c...) android_clang_dbg on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/android_clang_dbg/bui...) android_dbg on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/android_dbg/builds/18...) chromium_presubmit on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/chromium_presubmit/bu...) linux_chromium_chromeos_clang_dbg on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_chrome...) linux_chromium_chromeos_rel on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_chrome...) linux_chromium_clang_dbg on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_clang_...) linux_chromium_gn_rel on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_gn_rel...) linux_chromium_rel on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_rel/bu...) mac_chromium_compile_dbg on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/mac_chromium_compile_...) mac_chromium_rel on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/mac_chromium_rel/buil...) win_chromium_compile_dbg on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/win_chromium_compile_...) win_chromium_rel on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/win_chromium_rel/buil...) win_chromium_x64_rel on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/win_chromium_x64_rel/...)
The CQ bit was unchecked by ericu@chromium.org
The CQ bit was checked by ericu@chromium.org
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/ericu@chromium.org/266333002/100001
FYI, CQ is re-trying this CL (attempt #1). Please consider checking whether the failures are real, and report flakes to chrome-troopers@google.com. The failing builders are: android_aosp on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/android_aosp/builds/7...) android_clang_dbg on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/android_clang_dbg/bui...) linux_chromium_chromeos_clang_dbg on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_chrome...) linux_chromium_chromeos_rel on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_chrome...) linux_chromium_clang_dbg on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_clang_...) linux_chromium_rel on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_rel/bu...) mac_chromium_compile_dbg on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/mac_chromium_compile_...) mac_chromium_rel on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/mac_chromium_rel/buil...)
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: android_clang_dbg on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/android_clang_dbg/bui...)
The CQ bit was checked by ericu@chromium.org
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/ericu@chromium.org/266333002/140001
Message was sent while issue was closed.
Change committed as 270016
Message was sent while issue was closed.
A revert of this CL has been created in https://codereview.chromium.org/288523002/ by vabr@chromium.org. The reason for reverting is: This seems to have broken some DB-related content_unittests http://build.chromium.org/p/chromium.win/builders/XP%20Tests%20%283%29/builds..., the stdio contains a couple of the following backtraces: [2092:3704:0512/235433:3686281:ERROR:indexed_db_backing_store.cc(376)] IndexedDB Write Error: SET_UP_METADATA Backtrace: (No symbol) [0x00B727AA] (No symbol) [0x00730997] (No symbol) [0x00D401E9] (No symbol) [0x00D4036E] (No symbol) [0x00D4094E] (No symbol) [0x00D40689] (No symbol) [0x00D1B0B8] (No symbol) [0x00D1ADE7] (No symbol) [0x00A6322D] (No symbol) [0x022D0761] RegisterWaitForInputIdle [0x7C816037+73].
Message was sent while issue was closed.
A revert of this CL has been created in https://codereview.chromium.org/280703007/ by rschoen@chromium.org. The reason for reverting is: Causing timeouts on indexeddb_perf tests. Log: http://build.chromium.org/p/chromium.perf/builders/Win%207%20Low-End%20Perf%2....
The CQ bit was checked by ericu@chromium.org
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/ericu@chromium.org/266333002/160001
Message was sent while issue was closed.
Change committed as 271097
The CQ bit was checked by ericu@chromium.org
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/ericu@chromium.org/266333002/310006
Message was sent while issue was closed.
Change committed as 273048 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
