New issue
Advanced search Search tips

Issue 878990 link

Starred by 3 users

Issue metadata

Status: Untriaged
Owner: ----
Cc:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug



Sign in to add a comment

FATAL:timer.cc(98)] Check failed: origin_sequence_checker_.CalledOnValidSequence()

Project Member Reported by alemate@chromium.org, Aug 30

Issue description

Chrome OS, Eve device, latest ToT (ebf6eeb9da9addf47e6ca899bf9a2a0f7e8a85cb). Crash on system start in Debug build:


[31553:31687:0829/161559.966794:FATAL:timer.cc(98)] Check failed: origin_sequence_checker_.CalledOnValidSequence(). 
#0 0x567d1538bdf8 base::debug::StackTrace::StackTrace()
#1 0x567d1512e75c base::debug::StackTrace::StackTrace()
#2 0x567d1517712a logging::LogMessage::~LogMessage()
#3 0x567d152e952e base::internal::TimerBase::GetCurrentDelay()
#4 0x567d152ea8ec base::RepeatingTimer::RunUserTask()
#5 0x567d152ea000 base::internal::TimerBase::RunScheduledTask()
#6 0x567d152ead79 base::internal::BaseTimerTaskInternal::Run()
#7 0x567d0b4e918d _ZN4base8internal13FunctorTraitsIMN3net16DnsConfigServiceEFvvEvE6InvokeIS5_PS3_JEEEvT_OT0_DpOT1_
#8 0x567d0b4e90d4 _ZN4base8internal12InvokeHelperILb0EvE8MakeItSoIMN3net16DnsConfigServiceEFvvEJPS5_EEEvOT_DpOT0_
#9 0x567d152eaef2 _ZN4base8internal7InvokerINS0_9BindStateIMNS0_21BaseTimerTaskInternalEFvvEJNS0_12OwnedWrapperIS3_EEEEEFvvEE7RunImplIS5_NSt3__15tupleIJS7_EEEJLm0EEEEvOT_OT0_NSC_16integer_sequenceImJXspT1_EEEE
#10 0x567d152eae29 _ZN4base8internal7InvokerINS0_9BindStateIMNS0_21BaseTimerTaskInternalEFvvEJNS0_12OwnedWrapperIS3_EEEEEFvvEE7RunOnceEPNS0_13BindStateBaseE
#11 0x567d0b5cc58c _ZNO4base12OnceCallbackIFvvEE3RunEv
#12 0x567d153d6408 base::debug::TaskAnnotator::RunTask()
#13 0x567d152c657c base::internal::TaskTracker::RunOrSkipTask()
#14 0x567d153ba566 base::internal::TaskTrackerPosix::RunOrSkipTask()
#15 0x567d152c4243 base::internal::TaskTracker::RunAndPopNextTask()
#16 0x567d15403822 base::internal::SchedulerWorker::RunWorker()
#17 0x567d15402f29 base::internal::SchedulerWorker::RunPooledWorker()
#18 0x567d15402daf base::internal::SchedulerWorker::ThreadMain()
#19 0x567d153bb966 base::(anonymous namespace)::ThreadFunc()
#20 0x7b751bd982b8 <unknown>
#21 0x7b751a79dfad clone

 
Are we sure this is coming from DNS? The only reference I see in the given backtrace is Frames #7 and #8 which name net::DnsConfigService from a templetized expasion of base::internal::FunctorTraits. I don't know that I trust this, given ambiguity in mapping these expansions back to the actual type.

Assuming this is in fact come from DnsConfigService, not sure how that would happen.

DnsConfigService uses a base::Timer, however guards access to it with DCHECK_CALLED_ON_VALID_THREAD. And the actual DCHECK looks to be coming from an internally posted task by the timer.

@gab: Could this be related to  Issue 587199 ?
Cc: gab@chromium.org
Components: -Internals>Network>DNS
This isn't DnsConfigService.  DnsConfigService uses a OneShotTimer but this call-stack contains RepeatingTimer.  The call-stack looks legitimate too: RepeatingTimer::RunUserTask() does call GetCurrentDelay(), while OneShotTimer::RunUserTask() does not.  I'd guess the DnsConfigService symbolication is a red herring caused by linker function deduplication.
Re #3: caused by linker function deduplication.

I would be very surprised if Debug build has this level of function deduplication.
Are you sure it's linker to be blamed?
If it's reproducible, you could probably append 
<< posted_from_.ToString()
to that DCHECK line to demistify it. That info might be already in any uploaded minidump (though I won't be able to extract it from a CrOS one)


Cc: -davidben@chromium.org -zhongyi@chromium.org -jkarlin@chromium.org -mef@chromium.org -rch@chromium.org -b...@chromium.org -asanka@chromium.org -rsleevi@chromium.org -nhar...@chromium.org -mmenke@chromium.org -mattm@chromium.org -agl@chromium.org
Seems rather unnecessary to CC the entire network stack team on a random crasher.  That really doesn't scale.  Not even seeing this as a top crasher on the crash server.  Removing everyone who didn't comment.
> I would be very surprised if Debug build has this level of function deduplication.

I believe we do linker function deduplication on ChromeOS always:
"chromeos binutils has been patched with the fix, so always use icf there."
https://cs.chromium.org/chromium/src/build/config/compiler/BUILD.gn?rcl=0f0b1aebcbf11c753048a2946b59d46f67405d89&l=156
To save folks the trouble, this is the original stack trace piped through c++filt:

[31553:31687:0829/161559.966794:FATAL:timer.cc(98)] Check failed: origin_sequence_checker_.CalledOnValidSequence(). 
#0 0x567d1538bdf8 base::debug::StackTrace::StackTrace()
#1 0x567d1512e75c base::debug::StackTrace::StackTrace()
#2 0x567d1517712a logging::LogMessage::~LogMessage()
#3 0x567d152e952e base::internal::TimerBase::GetCurrentDelay()
#4 0x567d152ea8ec base::RepeatingTimer::RunUserTask()
#5 0x567d152ea000 base::internal::TimerBase::RunScheduledTask()
#6 0x567d152ead79 base::internal::BaseTimerTaskInternal::Run()
#7 0x567d0b4e918d void base::internal::FunctorTraits<void (net::DnsConfigService::*)(), void>::Invoke<void (net::DnsConfigService::*)(), net::DnsConfigService*>(void (net::DnsConfigService::*)(), net::DnsConfigService*&&)
#8 0x567d0b4e90d4 void base::internal::InvokeHelper<false, void>::MakeItSo<void (net::DnsConfigService::*)(), net::DnsConfigService*>(void (net::DnsConfigService::*&&)(), net::DnsConfigService*&&)
#9 0x567d152eaef2 void base::internal::Invoker<base::internal::BindState<void (base::internal::BaseTimerTaskInternal::*)(), base::internal::OwnedWrapper<base::internal::BaseTimerTaskInternal> >, void ()>::RunImpl<void (base::internal::BaseTimerTaskInternal::*)(), std::__1::tuple<base::internal::OwnedWrapper<base::internal::BaseTimerTaskInternal> >, 0ul>(void (base::internal::BaseTimerTaskInternal::*&&)(), std::__1::tuple<base::internal::OwnedWrapper<base::internal::BaseTimerTaskInternal> >&&, std::__1::integer_sequence<unsigned long, 0ul>)
#10 0x567d152eae29 base::internal::Invoker<base::internal::BindState<void (base::internal::BaseTimerTaskInternal::*)(), base::internal::OwnedWrapper<base::internal::BaseTimerTaskInternal> >, void ()>::RunOnce(base::internal::BindStateBase*)
#11 0x567d0b5cc58c base::OnceCallback<void ()>::Run() &&
#12 0x567d153d6408 base::debug::TaskAnnotator::RunTask()
#13 0x567d152c657c base::internal::TaskTracker::RunOrSkipTask()
#14 0x567d153ba566 base::internal::TaskTrackerPosix::RunOrSkipTask()
#15 0x567d152c4243 base::internal::TaskTracker::RunAndPopNextTask()
#16 0x567d15403822 base::internal::SchedulerWorker::RunWorker()
#17 0x567d15402f29 base::internal::SchedulerWorker::RunPooledWorker()
#18 0x567d15402daf base::internal::SchedulerWorker::ThreadMain()
#19 0x567d153bb966 base::(anonymous namespace)::ThreadFunc()
#20 0x7b751bd982b8 <unknown>
#21 0x7b751a79dfad clone
Though I guess, given the linker deduplication, the parts of the stack that got demangled are totally useless anyway. :-)

Sign in to add a comment