-
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
intl test timing out on Dartium bots #19544
Comments
Looking at the bots at the moment I'm not seeing any timeouts, but I am seeing problems where a test failure seems to come out as a runtime error. The failure is due to dartbug.com/15560 , where on the VM date creation in the local time zone occasionally gives the wrong answer. e.g. stdout: |
Thanks, Alan. I marked pkg/intl/test/date_time_format_http_request_test as Pass, Timeout to keep the bots happy. I'm still seeing timeouts (or very long runs for it) locally. Do you think this is due to 15560 as well? If so, is there a way to get this test to fail fast instead of timing out? It's taking a good chunk of time. |
Well, I don't seem to be able to run Dartium tests on either of my machines, so it's hard to tell much. There's a lot of logging in there to try to isolate the 15560 problem. We could remove that, and it might speed things up. But it seems strange that this started happening a few days ago, and suggests something else that changed. It sort of looks like it might be putting up a dialog when there's a failure, and I can believe that would cause a timeout. If so, fixing that seems like a good idea, and it might well be affecting other tests as well. But that's a wild guess. If you run it locally and it times out, what do you see for a log. In particular, it's useful to know if it's just being slow running the tests and runs out of time or if it freezes when it gets a problem. If the former then profiling might be useful, and removing the logging might help. If the latter it seems like it's the error handling. I can also do some kind of duct tape workaround like checking if the local time zone is the same as UTC and retrying once if it is. |
Found another log with more information which suggests that it's a timeout trying to get the locale data from the HTTP server, and taking 120 seconds. I'll try at least setting a timeout on the request. |
Added Pkg-Intl label. |
This comment was originally written by whesse@chromium.org We are now getting two more tests to time out flakily as well, on android content_shell and on macos dartium: |
This issue has been moved to dart-lang/i18n#313. |
This test is timing out sporadically on drt and dartium on different OSes. Started in the past day.
FAILED: none-drt-checked release_x64 pkg/intl/test/date_time_format_http_request_test
Expected: Pass
Actual: Timeout
CommandOutput[content_shell]:
stdout:
READY
stderr:
[9292:9292:0619/030744:3196644067:ERROR:browser_main_loop.cc(163)] Running without the SUID sandbox! See https://code.google.com/p/chromium/wiki/LinuxSUIDSandboxDevelopment for more information on developing with the sandbox on.
[9292:9292:0619/030744:3197010234:WARNING:webrtc_internals.cc(52)] Could not get the download directory.
To retest, run: /mnt/data/b/build/slave/dartium-lucid64-full-be/build/src/dart//tools/testing/bin/linux/dart /mnt/data/b/build/slave/dartium-lucid64-full-be/build/src/dart/tools/testing/dart/http_server.dart -p 39869 -c 38498 --build-directory=/mnt/data/b/build/slave/dartium-lucid64-full-be/build/src/out/Release --runtime=drt
Command[content_shell]: /mnt/data/b/build/slave/dartium-lucid64-full-be/build/src/out/Release/content_shell --no-timeout --dump-render-tree http://127.0.0.1:39869/root_build/generated_tests/none-drt-checked/pkg_intl_test_date_time_format_http_request_test/test.html?crossOriginPort=38498
Took 0:04:00.209000
Short reproduction command (experimental):
python tools/test.py -rdrt -mrelease -ax64 --checked -t240 pkg/intl/test/date_time_format_http_request_test
Done none-drt-checked release_x64 pkg/intl/test/date_time_format_http_request_test: fail
@@@STEP_CLEAR@@@
The text was updated successfully, but these errors were encountered: