Bug 36471 - Assertion failure in WebCoreJSClientData::forgetWorld in storage tests
Summary: Assertion failure in WebCoreJSClientData::forgetWorld in storage tests
Status: RESOLVED WORKSFORME
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac (Intel) OS X 10.5
: P1 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-22 17:44 PDT by Eric U.
Modified: 2010-04-07 06:24 PDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eric U. 2010-03-22 17:44:31 PDT
I run the following in a clean client on OSX [10.5.8]:

% ./WebKitTools/Scripts/run-webkit-tests --debug --repeat-each 5 storage

Most of the time I'll get at least one crash in storage/open-database-creation-callback.html.  Here's the stderr output:

ASSERTION FAILED: m_worldSet.contains(world)
(/Users/ericu/three/src/third_party/WebKit/WebCore/bindings/js/WebCoreJSClientData.h:65 void WebCore::WebCoreJSClientData::forgetWorld(WebCore::DOMWrapperWorld*))

Note that this doesn't happen when I run without the --repeat-each flag.
Comment 1 Dumitru Daniliuc 2010-03-22 18:37:29 PDT
I suspect the problem is triggered by the open-database-creation-callback-isolated-world.html test. open-database-creation-callback.html probably just happens to run next and that's when the GC kicks in and tries to clean up the isolated world set up in the previous test (gotta love failures assigned to incorrect tests...).

Adam, any idea what might be the problem here? Is it possible that on shutdown forgetWorld() is called after (or at the same time but on a different thread) ~WebCoreJSClientData()?
Comment 2 Adam Barth 2010-03-25 15:53:53 PDT
I don't have a complete understanding of how isolated world are implemented in JSC.  Maybe we're not grabbing a reference to the world object in the right place?
Comment 3 Dumitru Daniliuc 2010-04-06 12:41:39 PDT
This assertion is now triggered every time run-webkit-tests is run on Windows (even without the --repeat flag).

Gavin, any idea how to fix this?

Raising to P1 since this affects 2 platforms now, and it pretty much blocks any WebKit development on Windows.
Comment 4 Adam Roben (:aroben) 2010-04-06 12:47:09 PDT
Why are we not seeing this on the bots? We have Debug test bots.
Comment 5 Dumitru Daniliuc 2010-04-06 18:56:48 PDT
(In reply to comment #4)
> Why are we not seeing this on the bots? We have Debug test bots.

It turns out that this happens for me (and not only on Windows) because of a patch I'm working on -- it saves the context in which each DB callback was created and calls each callback in the correct context. So it seems that the problem shows up when WebCoreJSClientData is used repeatedly (with my patch, each DB test would have a few callbacks that need to be called in the right context).
Comment 6 Adam Roben (:aroben) 2010-04-07 06:24:07 PDT
(In reply to comment #5)
> (In reply to comment #4)
> > Why are we not seeing this on the bots? We have Debug test bots.
> 
> It turns out that this happens for me (and not only on Windows) because of a
> patch I'm working on -- it saves the context in which each DB callback was
> created and calls each callback in the correct context. So it seems that the
> problem shows up when WebCoreJSClientData is used repeatedly (with my patch,
> each DB test would have a few callbacks that need to be called in the right
> context).

Sounds like we don't need a bug tracking this, then. The bug doesn't even exist, yet, and hopefully you can fix it before you land your patch.