DCHECK indicating corruption of internal state of PersistentNode.h(69): Check failed: !node || node->IsUnused(). |
|||||
Issue descriptionRepro steps: 1. Patch in https://codereview.chromium.org/2875793002 2. Build browser_tests 3. DISPLAY=:20 out/gn/browser_tests --gtest_filter=*ExtensionApiTabTest.TabUpdate* 4. Observe a DCHECK: [1:1:0510/135608.648852:FATAL:PersistentNode.h(69)] Check failed: !node || node->IsUnused(). The DCHECK happens when WebViewImpl's constructor assigns a (seemingly?) unrelated instance dev_tools_emulator_ = DevToolsEmulator::Create(this); The callstack when the DCHECK happens: base::debug::StackTrace::StackTrace() logging::LogMessage::~LogMessage() blink::PersistentNode::FreeListNext() blink::PersistentRegion::AllocatePersistentNode() blink::PersistentBase<>::Initialize() blink::WebViewImpl::WebViewImpl() blink::WebViewImpl::Create() content::RenderViewImpl::Initialize() content::RenderViewImpl::Create() content::RenderThreadImpl::CreateView() content::mojom::RendererStubDispatch::Accept()
,
May 11 2017
BTW: This is not necessarily related to the DCHECK in #c1 and in the original repro steps, but I did notice that PersistentNode deletes the copy assignment operator, but (unlike DISALLOW_COPY_AND_ASSIGN from base/macros.h) it doesn't delete the copy constructor. If this is intentional, we probably should add a comment to PersistentNode; otherwise we should delete the copy constructor as well. FWIW, the following compiles: PersistentNode x; PersistentNode x2(x); // copy constructor works fine - intentional? PersistentNode x5; // x5 = x; // compiler error: overload resolution selected deleted operator '=' PersistentNode x3(std::move(x)); // move constructor works fine PersistentNode x4; // This doesn't work, because copy assignment operator was deleted, but it // wasn't obvious to me at all, even after reading // http://en.cppreference.com/w/cpp/language/move_assignment (it wasn't // immediately obvious to me that "there are no user-declared copy assignment // operators" is violated - I didn't know that a deleted operator is a // user-declared operator).. // x4 = std::move(x); // compiler error: overload resolution selected deleted operator '='
,
May 12 2017
Re #1: Ah! You cannot use 0 and -1 for the hash key! These values are treated as deleted buckets. This is not a bug of Oilpan but a semantics of WTF's hashmap. yutak@: We should really document that behavior somewhere... Can we explain the crash in #0 for the same reason?
,
Jun 2 2017
,
Jul 5 2017
Can this bug be possibly related to go/chromepostmortem437? How can I ensure a Blink>MemoryAllocator>GarbageCollection bug gets triaged?
,
Jul 12 2017
haraken@, is this something you could triage further please?
,
Jul 13 2017
I don't think it's related to go/chromepostmortem437. The crash is specific to MediaQuery. Either way this looks like a bug of Oilpan. keishi-san, would you take a look? |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by lukasza@chromium.org
, May 11 2017I can hit a slightly different DCHECK with a smaller, but similar repro: TEST(PersistentTest, AsHashMapValue) { HashMap<int, Persistent<Receiver>> map; for (int i = 0; i < 2; i++) map.insert(i, new Receiver); } HashTable.h(1287): Check failed: !IsEmptyOrDeletedBucket(*entry)