Bug 85473

Summary: IconDatabase thread causes assertion failure: m_verifier.isSafeToUse()
Product: WebKit Reporter: Dongseong Hwang <dongseong.hwang>
Component: WebCore Misc.Assignee: Nobody <webkit-unassigned>
Status: RESOLVED DUPLICATE    
Severity: Normal CC: andersca, ap, beidson, darin, levin, yong.li.webkit
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
patch v.1 levin: review-, levin: commit-queue-

Dongseong Hwang
Reported 2012-05-03 04:01:30 PDT
adopted(RefCountedBase*) means new start of ia refCounted instance. RefPtr::release calls WTF::adopted to reset, so RefCounted thread verification code should reset. SharedBuffer used by IconDatabase causes the assertion failure because IconDatabase passes SharedBuffer to main thread.
Attachments
patch v.1 (1.97 KB, patch)
2012-05-03 04:03 PDT, Dongseong Hwang 		levin: review-
levin: commit-queue-
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Dongseong Hwang
Comment 1 2012-05-03 04:03:36 PDT
Created attachment 139981 [details] patch v.1
Dongseong Hwang
Comment 2 2012-05-03 04:10:16 PDT
Following code causes assertion failure. In IconDatabase.cpp RefPtr<SharedBuffer> data = dataOriginal ? dataOriginal->copy() : PassRefPtr<SharedBuffer>(0); .... { MutexLocker locker(m_urlAndIconLock); .... // Update the data and set the time stamp icon->setImageData(data.release()); .... }
David Levin
Comment 3 2012-05-03 07:24:14 PDT
Comment on attachment 139981 [details] patch v.1 adopted just means that a refcount that wasn't accounted for now is. This is no reason to reset the verifier. Something is wrong in this code and this change just attempts to hide the problem.
David Levin
Comment 4 2012-05-03 07:30:34 PDT
If you want to understand the assert, figure out what invariant is being violated when the assert goes off and either why that invariant is incorrect or how to fix the code. Note here is a similar bug: https://bugs.webkit.org/show_bug.cgi?id=67582 (Perhaps it is the same issue. It is hard to tell from what is in this bug.)
Dongseong Hwang
Comment 5 2012-05-03 21:28:13 PDT
Ok, I made mistake that I thought RefPtr::release means passing ownership. I need to study more about this bug, and if it is duplicated with Bug 67582, I will close this bug.
David Levin
Comment 6 2012-05-03 21:29:53 PDT
(In reply to comment #5) > Ok, I made mistake that I thought RefPtr::release means passing ownership. It means passing ownership of that one ref count but other places may have a ref on the object (and they do in this case). > I need to study more about this bug, and if it is duplicated with Bug 67582, I will close this bug. I think the only thing stopping bug 67582 is some wierd windows compile error. I wish we could land it.
Yong Li
Comment 7 2012-05-24 14:57:16 PDT
*** This bug has been marked as a duplicate of bug 67582 ***
Note You need to log in before you can comment on or make changes to this bug.