WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
Bug 58871
[Qt] REGRESSION(84176): http/tests/xmlhttprequest/event-listener-gc.html fails
https://bugs.webkit.org/show_bug.cgi?id=58871
Summary
[Qt] REGRESSION(84176): http/tests/xmlhttprequest/event-listener-gc.html fails
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
Add attachment
proposed patch, testcase, etc.
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.
Top of Page
Format For Printing
XML
Clone This Bug