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    

Csaba Osztrogonác
Reported 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.
Attachments
Csaba Osztrogonác
Comment 1 2011-04-19 06:04:53 PDT
I can reproduce it on 84176 (with 84178 and 84186), but I can't on 84175.
Csaba Osztrogonác
Comment 2 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
Csaba Osztrogonác
Comment 3 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.
Csaba Osztrogonác
Comment 4 2011-04-19 07:55:07 PDT
Oliver, Geoff, Zoltan have you got any idea what happened?
Csaba Osztrogonác
Comment 5 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. )
Oliver Hunt
Comment 6 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.
Luiz Agostini
Comment 7 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?
Note You need to log in before you can comment on or make changes to this bug.