Bug 49749 – [Qt] plugins/refcount-leaks.html fails, wrong ref count of npobject

• Status: RESOLVED
• Resolution: FIXED
• Component: Plug-ins

[Tony Chang]

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

[Tony Chang]

Skipped: http://trac.webkit.org/changeset/72313

[Robert Hogan]

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;

[Robert Hogan]

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.

[Siddharth Mathur]

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?

[Oliver Hunt]

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

[Ádám Kallai]

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

[Csaba Osztrogonác]

plugin tests is skipped on Qt WK for some reason.
In this case we can unskip it and close the bug.

[Ádám Kallai]

Thanks for your help. I'm going to remove it from the Qt Test Expetions. After that I will close the bug.

[Ádám Kallai]

I unskipped it: http://trac.webkit.org/changeset/130385
Closing bug.