Singleton Not Allowed on BluetoothTaskManagerWin's SequencedWorkerPool |
||||
Issue descriptionDCHECK here: 0:031> kn20 # ChildEBP RetAddr 00 3dd6ef64 100b378d base!base::debug::BreakDebugger+0x17 01 3dd6f4d0 1021e1ed base!logging::LogMessage::~LogMessage+0x2bd 02 3dd6f590 034d0938 base!base::ThreadRestrictions::AssertSingletonAllowed+0xbd 03 3dd6f5a4 034d07bf net!base::LazyInstance<`anonymous namespace'::WinsockInitSingleton,base::DefaultLazyInstanceTraits<`anonymous namespace'::WinsockInitSingleton> >::Pointer+0x18 04 3dd6f5b0 034d079d net!base::LazyInstance<`anonymous namespace'::WinsockInitSingleton,base::DefaultLazyInstanceTraits<`anonymous namespace'::WinsockInitSingleton> >::Get+0xf 05 3dd6f5b8 0f208055 net!net::EnsureWinsockInit+0xd 06 3dd6f6ac 0f20bdc9 bluetooth!device::BluetoothTaskManagerWin::DiscoverServices+0xc5 07 3dd6f6c4 0f208791 bluetooth!device::BluetoothTaskManagerWin::SearchDevices+0x49 08 3dd6f718 0f209907 bluetooth!device::BluetoothTaskManagerWin::GetKnownDevices+0x51 09 3dd6f834 0f20ca93 bluetooth!device::BluetoothTaskManagerWin::PollAdapter+0x107 0a 3dd6f940 0f1fb4e8 bluetooth!device::BluetoothTaskManagerWin::StartPolling+0xd3 0b 3dd6f94c 0f1fc308 bluetooth!base::internal::FunctorTraits<void (__thiscall device::BluetoothTaskManagerWin::*)(void),void>::Invoke<scoped_refptr<device::BluetoothTaskManagerWin> const &>+0x18 0c 3dd6f960 0f1fcd24 bluetooth!base::internal::InvokeHelper<0,void>::MakeItSo<void (__thiscall device::BluetoothTaskManagerWin::*const &)(void),scoped_refptr<device::BluetoothTaskManagerWin> const &>+0x28 0d 3dd6f970 0f20b794 bluetooth!base::internal::Invoker<base::internal::BindState<void (__thiscall device::BluetoothTaskManagerWin::*)(void),scoped_refptr<device::BluetoothTaskManagerWin> >,void __cdecl(void)>::RunImpl<void (__thiscall device::BluetoothTaskManagerWin::*const &)(void),std::tuple<scoped_refptr<device::BluetoothTaskManagerWin> > const &,0>+0x34 0e 3dd6f98c 1003d02e bluetooth!base::internal::Invoker<base::internal::BindState<void (__thiscall device::BluetoothTaskManagerWin::*)(void),scoped_refptr<device::BluetoothTaskManagerWin> >,void __cdecl(void)>::Run+0x24 0f 3dd6f9a0 101fdbfd base!base::Callback<void __cdecl(void),1>::Run+0x1e 10 3dd6fe58 101fcd2c base!base::SequencedWorkerPool::Inner::ThreadLoop+0x3bd 11 3dd6ff30 102097e9 base!base::SequencedWorkerPool::Worker::Run+0xec 12 3dd6ff5c 101ef22c base!base::SimpleThread::ThreadMain+0x79
,
Jul 21 2016
Could you provide more information about the reproduce steps and phenomenon?
,
Jul 21 2016
adding gab who recently changed the windows code to use SequencedWorkerPool.
,
Jul 21 2016
This repros on a debug build at startup for Chrome. Because this thread is non-joinable, you'll want to do the singleton init elsewhere.
,
Jul 21 2016
Okay, looks gab@ might have better idea of this issue,
,
Jul 21 2016
Note that this repro's even without gab@'s change. It seems that this singleton access is now the first access.
,
Jul 22 2016
This is surprising to me because the SequencedWorkerPool's threads should be joinable (they are base::SimpleThreads which are joinable). But either way, looks like the desire is for EnsureWinsockInit to be leaky anyways (we no-op in destructor). So the solution is just to be make the LazyInstance use ::Leaky (and = delete; the destructor to enforce that it's never deleted).
,
Jul 22 2016
Oh actually, this is because it's posting tasks as CONTINUE_ON_SHUTDOWN [1], that's what makes it not be allowed to use singletons as of r406293 by pmonette@. Solution is as described in #7. Make the LazyInstance::Leaky and = delete; the destructor. [1] https://cs.chromium.org/chromium/src/device/bluetooth/bluetooth_task_manager_win.cc?rcl=0&l=263
,
Jul 26 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b6b9526b59d2f82b7dc6b4822643fabdc987a6b6 commit b6b9526b59d2f82b7dc6b4822643fabdc987a6b6 Author: gab <gab@chromium.org> Date: Tue Jul 26 20:36:38 2016 Update AssertSingletonAllowed log message to reflect new restrictions w.r.t. CONTINUE_ON_SHUTDOWN tasks. This came up on issue 630059 , the log message should reflect the new reasons why it may occur. BUG= 630059 Review-Url: https://codereview.chromium.org/2173903002 Cr-Commit-Position: refs/heads/master@{#407906} [modify] https://crrev.com/b6b9526b59d2f82b7dc6b4822643fabdc987a6b6/base/threading/thread_restrictions.cc
,
Jul 27 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/bc52bc570ca268020b38e2dbca4b37f5ff7da917 commit bc52bc570ca268020b38e2dbca4b37f5ff7da917 Author: gogerald <gogerald@chromium.org> Date: Wed Jul 27 14:20:00 2016 Make WinsockInitSingleton explicitly leaky to avoid the AssertSingletonAllowed() dcheck. BUG= 630059 Review-Url: https://codereview.chromium.org/2183253002 Cr-Commit-Position: refs/heads/master@{#408117} [modify] https://crrev.com/bc52bc570ca268020b38e2dbca4b37f5ff7da917/net/base/winsock_init.cc
,
Aug 1 2016
Issue 630814 has been merged into this issue.
,
Aug 9 2016
Fixed, right? |
||||
►
Sign in to add a comment |
||||
Comment 1 by scheib@chromium.org
, Jul 21 2016