Chrome: Crash Report - [ThreadWatcher IO hang] disk_cache::MemEntryImpl::GetChild |
|||
Issue descriptionreporter:morlovich@google.com Magic Signature: [ThreadWatcher IO hang] disk_cache::MemEntryImpl::GetChild Crash link: https://crash.corp.google.com//browse?q=product.name%3D'Chrome'%20AND%20product.version%3D'66.0.3333.0'%20AND%20expanded_custom_data.ChromeCrashProto.channel%3D'canary'%20AND%20expanded_custom_data.ChromeCrashProto.ptype%3D'browser'%20AND%20expanded_custom_data.ChromeCrashProto.magic_signature_1.name%3D'%5BThreadWatcher%20IO%20hang%5D%20disk_cache%3A%3AMemEntryImpl%3A%3AGetChild'%20AND%20ReportID%3D'1bc04dd302e06859'#3 ------------------------------------------------------------------------------- Sample Report ------------------------------------------------------------------------------- Product name: Chrome Magic Signature : [ThreadWatcher IO hang] disk_cache::MemEntryImpl::GetChild Product Version: 66.0.3333.0 Process type: browser Report ID: 1bc04dd302e06859 Report Url: https://crash.corp.google.com/1bc04dd302e06859 Report Time: 2018-01-27T12:19:11-08:00 Upload Time: 2018-01-27T12:19:16.004-08:00 Uptime: 2772000 ms CumulativeProductUptime: 0 ms OS Name: Windows NT OS Version: 10.0.16299 15 CPU Architecture: amd64 CPU Info: family 6 model 61 stepping 4 ------------------------------------------------------------------------------- Crashing thread: Thread index: 12. Stack Quality: 100%. Thread id: 4312. ------------------------------------------------------------------------------- 0x00007ffc39c777d0 (chrome.dll - xhash: 645) std::_Hash<std::_Umap_traits<int,CastRemotingConnector *,std::_Uhash_compare<int,std::hash<int>,std::equal_to<int> >,std::allocator<std::pair<const int,CastRemotingConnector *> >,0> >::lower_bound 0x00007ffc3ad40367 (chrome.dll - mem_entry_impl.cc: 583) disk_cache::MemEntryImpl::GetChild(__int64,bool) 0x00007ffc3ad4040c (chrome.dll - mem_entry_impl.cc: 601) disk_cache::MemEntryImpl::FindNextChild(__int64,int,disk_cache::MemEntryImpl * *) 0x00007ffc3ad3ff72 (chrome.dll - mem_entry_impl.cc: 533) disk_cache::MemEntryImpl::InternalGetAvailableRange(__int64,int,__int64 *) 0x00007ffc3ad3fea9 (chrome.dll - mem_entry_impl.cc: 254) disk_cache::MemEntryImpl::GetAvailableRange(__int64,int,__int64 *,base::RepeatingCallback<void > const &) 0x00007ffc3ad7982d (chrome.dll - partial_data.cc: 113) net::PartialData::ShouldValidateCache(disk_cache::Entry *,base::RepeatingCallback<void > const &) 0x00007ffc39e4154b (chrome.dll - http_cache_transaction.cc: 890) net::HttpCache::Transaction::DoLoop(int) 0x00007ffc3acbaa10 (chrome.dll - http_cache.cc: 1299) net::HttpCache::OnProcessQueuedTransactions(net::HttpCache::ActiveEntry *) 0x00007ffc39c0ed09 (chrome.dll - task_annotator.cc: 53) base::debug::TaskAnnotator::RunTask(char const *,base::PendingTask *) 0x00007ffc39c0e5eb (chrome.dll - message_loop.cc: 399) base::MessageLoop::RunTask(base::PendingTask *) 0x00007ffc39c0dee9 (chrome.dll - message_loop.cc: 462) base::MessageLoop::DoWork() 0x00007ffc39c1e380 (chrome.dll - message_pump_win.cc: 475) base::MessagePumpForIO::DoRunLoop() 0x00007ffc39c1e217 (chrome.dll - message_pump_win.cc: 56) base::MessagePumpWin::Run(base::MessagePump::Delegate *) 0x00007ffc39c0d8e4 (chrome.dll - run_loop.cc: 130) base::RunLoop::Run() 0x00007ffc39cc7f37 (chrome.dll - browser_thread_impl.cc: 248) content::BrowserThreadImpl::IOThreadRun(base::RunLoop *) 0x00007ffc39ca5d1d (chrome.dll - browser_thread_impl.cc: 283) content::BrowserThreadImpl::Run(base::RunLoop *) 0x00007ffc39c0c909 (chrome.dll - thread.cc: 338) base::Thread::ThreadMain() 0x00007ffc3ab0b2c4 (chrome.dll - platform_thread_win.cc: 91) base::`anonymous namespace'::ThreadFunc 0x00007ffc7b321fe3 (KERNEL32.DLL + 0x00011fe3) BaseThreadInitThunk 0x00007ffc7d28efb0 (ntdll.dll + 0x0006efb0) RtlUserThreadStart
,
Feb 6 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/65f2cba2a21f771dc5d69c46bde9d1e3a93ed1f9 commit 65f2cba2a21f771dc5d69c46bde9d1e3a93ed1f9 Author: Maks Orlovich <morlovich@chromium.org> Date: Tue Feb 06 18:39:24 2018 disk_cache::MemBackend --- fix GetAvailableRange over big, sparse ranges Previous code both would perform very badly --- as it's scanning over 4K increments, which is iffy if there is a big hole in the middle --- and could also suffer from wrap around in index computations (an alternative may be to fix just that...) This change replace hash table keeping track of ranges with the ordered std::map, which makes finding adjacent kids easy. Bug: 808561 Change-Id: I3442bbbf6c0e4bc6089ba89265ebb27d739d7edc Reviewed-on: https://chromium-review.googlesource.com/901862 Commit-Queue: Maks Orlovich <morlovich@chromium.org> Reviewed-by: Matt Menke <mmenke@chromium.org> Cr-Commit-Position: refs/heads/master@{#534731} [modify] https://crrev.com/65f2cba2a21f771dc5d69c46bde9d1e3a93ed1f9/net/disk_cache/entry_unittest.cc [modify] https://crrev.com/65f2cba2a21f771dc5d69c46bde9d1e3a93ed1f9/net/disk_cache/memory/mem_entry_impl.cc [modify] https://crrev.com/65f2cba2a21f771dc5d69c46bde9d1e3a93ed1f9/net/disk_cache/memory/mem_entry_impl.h
,
Feb 6 2018
Versions link (fix not in any thus far, but just getting ready): https://crash.corp.google.com/browse?q=product.name%20LIKE%27Chrome%25%27%20AND%20expanded_custom_data.ChromeCrashProto.channel%3D%27canary%27%20AND%20expanded_custom_data.ChromeCrashProto.ptype%3D%27browser%27%20AND%20expanded_custom_data.ChromeCrashProto.magic_signature_1.name%3D%27%5BThreadWatcher%20IO%20hang%5D%20disk_cache%3A%3AMemEntryImpl%3A%3AGetChild%27#samplereports
,
Feb 12 2018
Commit 65f2cba2... initially landed in 66.0.3342.0 Last version that has reports is 3341, about 5 days ago.
,
Mar 2 2018
|
|||
►
Sign in to add a comment |
|||
Comment 1 by morlovich@chromium.org
, Feb 2 2018Owner: morlovich@chromium.org
Status: Started (was: Untriaged)
So this might be something real. For starters MemEntryImpl::FindNextChild is very inefficient when run over a very sparse range; as it just jumps by 4K trying to find what doesn't have holes. Using a map rather than an unordered_map for its data structure may be better. Here is what the state is: dv this = 0x0000018e`edacc4c0 offset = 0n79790080 len = 0n2147483647 child = 0x0000001c`c23ff2a8 scanned_len = 0n-652550144 Note the len and offset. len this large (max_int32, basically) is what PartialData uses when it doesn't know the range. What's especially worrying is scanned_len; I think it can overflow?