New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 801252 link

Starred by 1 user

Issue metadata

Status: Duplicate
Owner: ----
Closed: Apr 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

[Assert] in syncer::SharedModelTypeProcessor::CreateEntity

Project Member Reported by w...@chromium.org, Jan 11 2018

Issue description

[19148:18028:0111/105001.631:FATAL:shared_model_type_processor.cc(773)] Check failed: entities_.find(data.client_tag_hash) == entities_.end(). .

00 chrome_5ad10000!base::debug::BreakDebugger
01 chrome_5ad10000!logging::LogMessage::~LogMessage
02 chrome_5ad10000!syncer::SharedModelTypeProcessor::CreateEntity
03 chrome_5ad10000!syncer::SharedModelTypeProcessor::Put
04 chrome_5ad10000!history::TypedURLSyncBridge::SendTypedURLToProcessor
05 chrome_5ad10000!history::TypedURLSyncBridge::UpdateSyncFromLocal
06 chrome_5ad10000!history::TypedURLSyncBridge::OnURLVisited
07 chrome_5ad10000!history::HistoryBackend::NotifyURLVisited
08 chrome_5ad10000!history::HistoryBackend::AddPageVisit
09 chrome_5ad10000!history::HistoryBackend::AddPage
0a chrome_5ad10000!base::internal::FunctorTraits<void (__thiscall history::HistoryBackend::*)(history::HistoryAddPageArgs const &),void>::Invoke
0b chrome_5ad10000!base::internal::InvokeHelper<0,void>::MakeItSo
0c chrome_5ad10000!base::internal::Invoker<base::internal::BindState<void (__thiscall history::HistoryBackend::*)(history::HistoryAddPageArgs const &),scoped_refptr<history::HistoryBackend>,history::HistoryAddPageArgs>,void __cdecl(void)>::RunImpl<void (__thiscall history::HistoryBackend::*const &)(history::HistoryAddPageArgs const &),std::tuple<scoped_refptr<history::HistoryBackend>,history::HistoryAddPageArgs> const &,0,1>
0d chrome_5ad10000!base::internal::Invoker<base::internal::BindState<void (__thiscall history::HistoryBackend::*)(history::HistoryAddPageArgs const &),scoped_refptr<history::HistoryBackend>,history::HistoryAddPageArgs>,void __cdecl(void)>::Run
0e chrome_5ad10000!base::OnceCallback<void __cdecl(void)>::Run
0f chrome_5ad10000!base::debug::TaskAnnotator::RunTask
10 chrome_5ad10000!base::internal::IncomingTaskQueue::RunTask
11 chrome_5ad10000!base::MessageLoop::RunTask
12 chrome_5ad10000!base::MessageLoop::DeferOrRunPendingTask
13 chrome_5ad10000!base::MessageLoop::DoWork
14 chrome_5ad10000!base::MessagePumpDefault::Run
15 chrome_5ad10000!base::MessageLoop::Run
16 chrome_5ad10000!base::RunLoop::Run
17 chrome_5ad10000!base::Thread::Run
18 chrome_5ad10000!base::Thread::ThreadMain
19 chrome_5ad10000!base::`anonymous namespace'::ThreadFunc
1a KERNEL32!BaseThreadInitThunk
1b ntdll!__RtlUserThreadStart
1c ntdll!_RtlUserThreadStart

For graphics-related bugs, please copy/paste the contents of the about:gpu
page at the end of this report.

 

Comment 1 by w...@chromium.org, Jan 11 2018

Components: Services>Sync
Labels: -Pri-3 M-65 Hotlist-Dcheck-Albatross OS-Windows Pri-2
See crash report 840808a95515d053 (though unfortunately the report is missing symbols, so can't be directly associated w/ this crash yet).

This repros trivially for me:
[0. Run SyzyASAN Canary and enable DCHECKs; this is configured by experiment for a small fraction of Canary users]
1. Open inbox.google.com.

Comment 2 by w...@chromium.org, Jan 11 2018

Missing symbols reported as issue 801251.

Comment 3 by s...@chromium.org, Jan 11 2018

If you this reproing for you locally, can you attach a copy of your history db? It seems to me this may be caused by two history rows that have different row ids, but when we try to get the url, it ends up evaluating to the same value.

Comment 4 by w...@chromium.org, Jan 11 2018

Cc: w...@chromium.org
Owner: s...@chromium.org
Status: Assigned (was: Untriaged)

Comment 5 by s...@chromium.org, Jan 12 2018

Cc: s...@chromium.org
Owner: ----
Status: Available (was: Assigned)
Unassigned so someone from the MUC side can pick this up. OP is able to reproduce reliably on their existing Windows profile, every time visiting "inbox.google.com", and using a debugger they can see that this is the url when the DCHECK is hit.

Other profiles syncing to the same account, or other profiles w/ a copied history db syncing to a different account does not seem to reproduce the issue. I looked through a copy of the History DB from the DCHECKing profile and it doesn't contain a simple "inbox.google.com" url, we assume because it DCHECKs before things can be serialized to disk.

I'm pretty confused as to what's going on here. Actually, now that I think about it, what if we had metadata that's not tied to url row id anymore because it was deleted. But it still gets loaded on start up. I don't know. Whoever picks this up should ask OP for a copy of their History DB.

Comment 6 by s...@chromium.org, Jan 17 2018

Labels: SyncHandoff2018
Mergedinto: 827111
Status: Duplicate (was: Available)

Comment 8 Deleted

Comment 9 Deleted

Sign in to add a comment