This test was added here: http://trac.webkit.org/changeset/72302 It tests that after a GC, an npobject has the right ref count. This is failing on QT (diff below). This might be intentional, maybe QT is holding a ref? Anyway, adding to the Skipped list for now. --- /home/webkitbuildbot/slaves/release32bit/buildslave/qt-linux-release/build/layout-test-results/plugins/refcount-leaks-expected.txt 2010-11-18 10:20:56.296133985 -0800 +++ /home/webkitbuildbot/slaves/release32bit/buildslave/qt-linux-release/build/layout-test-results/plugins/refcount-leaks-actual.txt 2010-11-18 10:20:56.296133985 -0800 @@ -7,6 +7,6 @@ --- refcount on plug.testObject: originally: 2 -after GC: 2 -after passing: 2 -SUCCESS +after GC: 3 +after passing: 3 +FAILURE
Skipped: http://trac.webkit.org/changeset/72313
Why does this allow the test to pass? --- a/LayoutTests/plugins/refcount-leaks.html +++ b/LayoutTests/plugins/refcount-leaks.html @@ -47,6 +47,7 @@ var o3 = plug.testObject; var refAfterGet = testObj.refCount; o1 = o2 = o3 = null; + output.innerHTML += ""; doGC(); var refAfterGetGC = testObj.refCount; @@ -55,6 +56,7 @@ plug.testPassTestObject("noop", testObj); plug.testPassTestObject("noop", testObj); plug.testPassTestObject("noop", testObj); + output.innerHTML += ""; doGC(); var refAfterPass = testObj.refCount;
A couple of things: 1. This test passes on a debug build but fails on a release build. Is there any general reason why GC is more aggressive in debug? 2. The failure starts here: // Test that the object refcount returns to normal after JS references // are released. var testObj = plug.testObject; var refOrig = testObj.refCount; var o1 = plug.testObject; var o2 = plug.testObject; var o3 = plug.testObject; var refAfterGet = testObj.refCount; o1 = o2 = o3 = null; doGC(); <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< var refAfterGetGC = testObj.refCount; My printf output on a debug build shows the three null'd references getting collected by the doGC(): Plugin Called: refCount _NPN_ReleaseVariantValue: 0xbfc4c278 3 GCController::garbageCollectNow() ~CInstance() releasing object entered _NPN_ReleaseObject _NPN_ReleaseObject obj->referenceCount: 0x8375628 5 _NPN_ReleaseObject obj->referenceCount: 0x8375628 4 ---------------------------------------------------- ~CInstance() releasing object entered _NPN_ReleaseObject _NPN_ReleaseObject obj->referenceCount: 0x8375628 4 _NPN_ReleaseObject obj->referenceCount: 0x8375628 3 ---------------------------------------------------- ~CInstance() releasing object entered _NPN_ReleaseObject _NPN_ReleaseObject obj->referenceCount: 0x8375628 3 _NPN_ReleaseObject obj->referenceCount: 0x8375628 2 ---------------------------------------------------- However on the release build only two are collected: Plugin Called: refCount _NPN_ReleaseVariantValue: 0xbf89221c 3 GCController::garbageCollectNow() ~CInstance() releasing object entered _NPN_ReleaseObject _NPN_ReleaseObject obj->referenceCount: 0x85687d0 5 _NPN_ReleaseObject obj->referenceCount: 0x85687d0 4 ---------------------------------------------------- ~CInstance() releasing object entered _NPN_ReleaseObject _NPN_ReleaseObject obj->referenceCount: 0x85687d0 4 _NPN_ReleaseObject obj->referenceCount: 0x85687d0 3 ---------------------------------------------------- GCController::garbageCollectNow() Plugin Called: refCount This failure cascades all the way through. 3. I've failed to find anything suspicious that is Qt-specific so far.
Oliver, Geof: do you have any pointers for Robert's question in Comment #3? I.e, where do dig for apparent different in GC behavior of release vs. debug builds?
Compiler will optimise usage of the stack differently between release and debug builds, and gc is dependent on values it finds in the stack. Simple scenario: JSCell* c = someGCValue; c->doSomethingCool(); JSCell* c2 = someOtherGCValue; c2->doSomethingCool(); doAFullGC(); In a debug build a compiler is almost certainly going to have a stackframe set up along the lines of: <--> slot for c slot for c2 <--> In a release build it will see that after c->doSomethingCool(), c is never used so will generate a frame akin to: <--> slot for c or c2 <--> In a debug build the gc will therefore see references to two values on the stack and keep them both alive, whereas in the release build there will be only one, so that the value originally held by c my become dead, and so be collected. This is the most obvious way that debug vs. release differences can influence gc
Is Anybody working this bug? I tested it. Now this test is working on Qt5-WK1, but It still fails on Qt5-WK2, because the WTR doesn't support it. Diff is here: --- /home/kadam/webkit/WebKit/WebKitBuild/Release/layout-test-results/plugins/refcount-leaks-expected.txt +++ /home/kadam/webkit/WebKit/WebKitBuild/Release/layout-test-results/plugins/refcount-leaks-actual.txt @@ -1,12 +1,5 @@ +CONSOLE MESSAGE: line 24: TypeError: 'undefined' is not a function (evaluating 'plug.testCreateTestObject()') Test that we can get an NPObject returned through a method on an NPAPI Object. Prints "SUCCESS" on success, "FAILURE" on failure. ---- num test objects: -countAfterCreate == countOrig + 3? PASS -countOrig == countAfterGC? PASS ---- refcount on plug.testObject: -originally: 2 -after GC: 2 -after passing: 2 -SUCCESS
plugin tests is skipped on Qt WK for some reason. In this case we can unskip it and close the bug.
Thanks for your help. I'm going to remove it from the Qt Test Expetions. After that I will close the bug.
I unskipped it: http://trac.webkit.org/changeset/130385 Closing bug.