Bug 58871

Summary: [Qt] REGRESSION(84176): http/tests/xmlhttprequest/event-listener-gc.html fails
Product: WebKit Reporter: Csaba Osztrogonác <ossy>
Component: Tools / TestsAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Critical CC: barraclough, cmarcelo, ggaren, luiz, oliver, ossy, zherczeg
Priority: P1 Keywords: Qt, QtTriaged
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Bug Depends on:    
Bug Blocks: 58718, 58853    

Description Csaba Osztrogonác 2011-04-19 01:57:28 PDT
After r84194, event handler doesn't fire after GC if we run all tests,
but it works if I run only http/tests/xmlhttprequest/event-listener-gc.html.

diff:
-----
--- /home/webkitbuildbot/slaves/release32bit/buildslave/qt-linux-release/build/layout-test-results/http/tests/xmlhttprequest/event-listener-gc-expected.txt	2011-04-19 01:47:51.694792438 -0700
+++ /home/webkitbuildbot/slaves/release32bit/buildslave/qt-linux-release/build/layout-test-results/http/tests/xmlhttprequest/event-listener-gc-actual.txt	2011-04-19 01:47:51.694792438 -0700
@@ -4,7 +4,4 @@
 
 If the test passes, you'll see a series of 'PASS' messages below.
 
-PASS: event handler fired after garbage collection.
-PASS: event handler fired after garbage collection.
-PASS: event handler fired after garbage collection.
Comment 1 Csaba Osztrogonác 2011-04-19 06:04:53 PDT
I can reproduce it on 84176 (with 84178 and 84186), but I can't on 84175.
Comment 2 Csaba Osztrogonác 2011-04-19 06:45:40 PDT
It caused one more fail on the debug bot:

--- /home/webkitbuildbot/slaves/debug32bit/buildslave/qt-linux-32-debug/build/layout-test-results/http/tests/security/mixedContent/insecure-plugin-in-iframe-expected.txt	2011-04-19 06:28:38.671792776 -0700
+++ /home/webkitbuildbot/slaves/debug32bit/buildslave/qt-linux-32-debug/build/layout-test-results/http/tests/security/mixedContent/insecure-plugin-in-iframe-actual.txt	2011-04-19 06:28:38.671792776 -0700
@@ -3,10 +3,10 @@
 frame "<!--framePath //<!--frame0-->-->" - didCommitLoadForFrame
 frame "<!--framePath //<!--frame0-->-->" - didFinishDocumentLoadForFrame
 frame "<!--framePath //<!--frame0-->-->" - didHandleOnloadEventsForFrame
-main frame - didHandleOnloadEventsForFrame
 CONSOLE MESSAGE: line 1: The page at https://127.0.0.1:8443/security/mixedContent/resources/frame-with-insecure-plugin.html ran insecure content from http://127.0.0.1:8000/security/mixedContent/resources/dummy.swf.
 
 didRunInsecureContent
+main frame - didHandleOnloadEventsForFrame
 frame "<!--framePath //<!--frame0-->-->" - didFinishLoadForFrame
 main frame - didFinishLoadForFrame
 This test loads a secure iframe that loads an insecure plugin. We should get a mixed content callback because the insecure plug-in can script the secure origin.



And two timeout:
- editing/text-iterator/basic-iteration.html 		
- fast/js/array-sort-modifying-tostring.html
Comment 3 Csaba Osztrogonác 2011-04-19 07:11:07 PDT
I rolled out the patches, because they caused strange GC related fails, timeouts: http://trac.webkit.org/changeset/84252

It needs more investigation, because reproducing this 
bug on a small example isn't so trivial task.
Comment 4 Csaba Osztrogonác 2011-04-19 07:55:07 PDT
Oliver, Geoff, Zoltan have you got any idea what happened?
Comment 5 Csaba Osztrogonác 2011-04-19 07:59:14 PDT
( Geoff is absolutely innocent, because first I thought that r84194 
was the culprit. I cc-ed Gavin, the reviewer of the patches. )
Comment 6 Oliver Hunt 2011-04-19 10:14:25 PDT
Csaba you need to remove the use of DeprecatedPtr from the qt bindings, either replace the DeprecatedPtr with a WriteBarrier or use Weak (or WeakGCMap) with the appropriate lifetime logic, or remove the method cache which is of questionable correctness.

We need to remove DeprecatedPtr as it will result in incorrect behaviour wherever it is used.
Comment 7 Luiz Agostini 2011-05-18 13:30:46 PDT
What is the status of this bug?

The patches in bug 58718 and bug 58853 were landed and they are both resolved as fixed. And the test http/tests/xmlhttprequest/event-listener-gc.html is not skipped nor failing.

Ossy, could we close this bug?