Failed ChromeOS recovery causes AssertIOAllwoed in dchecks build.
Reported by
faketast...@gmail.com,
May 24 2016
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.47 Safari/537.36 Steps to reproduce the problem: 1. Build Chrome with dcheck_always_on 2. Install https://chrome.google.com/webstore/detail/chromebook-recovery-utili/jndclpdbaamdhonoechobihbbiimdgai 3. When UAC dialog comes up, click "No". What is the expected behavior? Browser doesn't crash. What went wrong? Browser crashes with stack trace: base!base::debug::BreakDebugger+0x11 base!logging::LogMessage::~LogMessage+0x216 base!base::ThreadRestrictions::AssertIOAllowed+0xa5 base!base::DeleteFileW+0x20 base!base::ScopedTempDir::Delete+0x8 base!base::ScopedTempDir::~ScopedTempDir+0x23 chrome_61cf0000!extensions::image_writer::Operation::~Operation+0x60 chrome_61cf0000!extensions::image_writer::WriteFromUrlOperation::`scalar deleting destructor'+0xb chrome_61cf0000!base::RefCountedThreadSafe<extensions::image_writer::Operation,base::DefaultRefCountedThreadSafeTraits<extensions::image_writer::Operation> >::DeleteInternal+0xa chrome_61cf0000!base::DefaultRefCountedThreadSafeTraits<extensions::image_writer::Operation>::Destruct+0xa chrome_61cf0000!base::RefCountedThreadSafe<extensions::image_writer::Operation,base::DefaultRefCountedThreadSafeTraits<extensions::image_writer::Operation> >::Release+0x1d chrome_61cf0000!scoped_refptr<extensions::image_writer::Operation>::Release+0x20 chrome_61cf0000!scoped_refptr<extensions::image_writer::Operation>::{dtor}+0x27 chrome_61cf0000!base::internal::BindState<base::internal::RunnableAdapter<void (__thiscall extensions::image_writer::Operation::*)(std::basic_string<char,std::char_traits<char>,std::allocator<char> > const &)>,void __cdecl(extensions::image_writer::Operation *,std::basic_string<char,std::char_traits<char>,std::allocator<char> > const &),extensions::image_writer::Operation * const>::{dtor}+0x27 chrome_61cf0000!base::internal::BindState<base::internal::RunnableAdapter<void (__thiscall extensions::image_writer::Operation::*)(std::basic_string<char,std::char_traits<char>,std::allocator<char> > const &)>,void __cdecl(extensions::image_writer::Operation *,std::basic_string<char,std::char_traits<char>,std::allocator<char> > const &),extensions::image_writer::Operation * const>::Destroy+0x33 base!base::internal::BindStateBase::Release+0x17 base!scoped_refptr<base::internal::BindStateBase>::Release+0x17 base!scoped_refptr<base::internal::BindStateBase>::{dtor}+0x1b base!scoped_refptr<base::internal::BindStateBase>::operator=+0x2c base!base::internal::CallbackBase<0>::operator=+0x2c base!base::internal::CallbackBase<1>::operator=+0x31 chrome_61cf0000!ImageWriterUtilityClient::Shutdown+0xbd base!base::Callback<void __cdecl(void),1>::Run+0x8 base!base::debug::TaskAnnotator::RunTask+0xf7 base!base::MessageLoop::RunTask+0x4bc base!base::MessageLoop::DeferOrRunPendingTask+0xab base!base::MessageLoop::DoWork+0x22b base!base::MessagePumpForIO::DoRunLoop+0xbc base!base::MessagePumpWin::Run+0x4a base!base::MessageLoop::RunHandler+0x67 base!base::RunLoop::Run+0x29 base!base::MessageLoop::Run+0x62 base!base::Thread::Run+0xb content!content::BrowserThreadImpl::IOThreadRun+0x20 content!content::BrowserThreadImpl::Run+0x16a base!base::Thread::ThreadMain+0x1d9 base!base::`anonymous namespace'::ThreadFunc+0x92 KERNEL32!BaseThreadInitThunk+0x24 ntdll_77e40000!__RtlUserThreadStart+0x2f ntdll_77e40000!_RtlUserThreadStart+0x1b WebStore page: https://chrome.google.com/webstore/detail/chromebook-recovery-utili/jndclpdbaamdhonoechobihbbiimdgai Did this work before? N/A Chrome version: 53.0.2746.0 Channel: n/a OS Version: 10.0 Flash Version: Shockwave Flash 22.0 r0
,
May 24 2016
Sigh! This happens because the ScopedTempDir::Delete callback that happens on the FILE thread fails. This causes ~ScopedTempDir when Operation is destroyed to also try to delete the temp dir. Because ~Operation ends up running in the IO thread, the assert triggers. This isn't a problem in release builds other than causing file-related jank on the IO thread when running the recovery utility.
,
May 24 2016
,
May 24 2016
A bit of searching suggests this might be caused by 392976
,
May 24 2017
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 29
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1163c4661cd1eb4b80cbc4620d9d07cdaaadf19a commit 1163c4661cd1eb4b80cbc4620d9d07cdaaadf19a Author: Anand K. Mistry <amistry@chromium.org> Date: Wed Aug 29 05:43:50 2018 Delete ScopedTempDir on a blocking thread in imageWriterPrivate If the call to Delete() when cleaning up fails, the ScopedTempDir's destructor will also try to delete the directory. Since Operation is bound to the UI thread, this may cause jank or DCHECK in a dchecks build. BUG= 614230 Change-Id: Ibb9f44e5e3c41b57342fd6566939215b405c4162 Reviewed-on: https://chromium-review.googlesource.com/1195204 Reviewed-by: Ben Wells <benwells@chromium.org> Commit-Queue: Anand Mistry <amistry@chromium.org> Cr-Commit-Position: refs/heads/master@{#587019} [modify] https://crrev.com/1163c4661cd1eb4b80cbc4620d9d07cdaaadf19a/chrome/browser/extensions/api/image_writer_private/destroy_partitions_operation.cc [modify] https://crrev.com/1163c4661cd1eb4b80cbc4620d9d07cdaaadf19a/chrome/browser/extensions/api/image_writer_private/operation.cc [modify] https://crrev.com/1163c4661cd1eb4b80cbc4620d9d07cdaaadf19a/chrome/browser/extensions/api/image_writer_private/operation.h [modify] https://crrev.com/1163c4661cd1eb4b80cbc4620d9d07cdaaadf19a/chrome/browser/extensions/api/image_writer_private/write_from_url_operation.cc
,
Aug 29
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by amistry@chromium.org
, May 24 2016Owner: amistry@chromium.org
Status: Started (was: Unconfirmed)