-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DART_FORWARDING_PRINT=1 causes test time out #15497
Comments
I'll take a look Set owner to @jacob314. |
I've rolled back the CLs to before John and my change and the issue still occurs. There is something very strange going on as I can reproduce it by running the command you suggest but not by running the 3 steps individually. E.g. Command[dart2js]: out/ReleaseIA32/dart-sdk/bin/dart2js --package-root=out/ReleaseIA32/packages/ --out=/usr/local/google/home/jacobr/src/dart5/dart/out/ReleaseIA32/generated_compilations/dart2js/tests_html_mutationobserver_test/test.js /usr/local/google/home/jacobr/src/dart5/dart/tests/html/mutationobserver_test.dart Command[content_shell]: /usr/local/google/home/jacobr/src/dartium10/src/out/Debug/content_shell --no-timeout --dump-render-tree http://127.0.0.1:35053/root_build/generated_tests/dart2js-drt-csp/tests_html_mutationobserver_test/test.html?crossOriginPort=54137&group=childList Dartium wasn't rolling for a couple days after I rebooted VSM's machine so many other CLs could have also triggered the issue. I would assign to Pete as he owns the mutation tests but he is OOF. |
This seems to be a dartium issue -- I don't think Pete can do anything about it. After the timeout happened on peters commit, he came to me and we looked into this and the issue turned out to be the environment variable (as peter mentioned). To be a bit concreter:
The reason why tools/test.py sets the environment variable is that our testing scripts needs to capture print() calls inside the dart VM to determine if a test finished [and it is very useful for debugging test failures if we have print() output]. The real question is why should this environment variable have an impact? We are executing dart2js compiled code after all (and no dart code). |
With the latest Dartium builds I cannot reproduce in release mode on Linux. In debug mode the test will fail for me but that is only because dart2js takes 90+ seconds to compile which blows past the 60 second timeout. With a longer timeout the test passes for both debug and release builds. Set owner to @peter-ahe-google. |
FWIW, I was never able to reproduce the problem on Mac. |
The problem reproduces on linux for me. I filed a duplicate bug - I'll mark it as duplicate. Added Triaged label. |
Issue #15579 has been merged into this issue. cc @blois. |
It is reproducing on linux running an up-to-date drt: |
This comment was originally written by whesse@chromium.org I have reproduced the problem, by putting quote marks around the URL with an & in it, when running content_shell from the command line. The content security policy is not important, and the DART_FORWARDING_PRINT environment variable doesn't matter. The only difference between content_shell hanging, and content_shell passing all tests, is whether the HTML file references the script "tests_html_mutationobserver_test/test.precompiled.js" or The hanging only occurs on content_shell with the --dump-render-tree option, not on chrome or dartium. Here is the command and output: [dart checkout]/client/tests/drt/content_shell --no-timeout --dump-render-tree "http://127.0.0.1:58584/root_build/generated_tests/dart2js-drt-checked-csp/tests_html_mutationobserver_test/test.html?crossOriginPort=58990&group=childList" So it looks like a content_shell and dart2js problem to me. |
Added Fixed label. |
This test started timing out:
python tools/test.py -mrelease -cdart2js -rdrt --use-sdk --write-debug-log --write-test-outcome-log --csp -t60 html/mutationobserver_test/childList
However, only when DART_FORWARDING_PRINT is set.
Tentatively assigning to John as this seems to correlate with some big changes he landed in http://src.chromium.org/viewvc/multivm?revision=1624&view=revision
However, it is also possible that it was in revision 1623 or 1625.
The text was updated successfully, but these errors were encountered: