Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
test: add --abort-on-timeout option to test.py #11086
test: add --abort-on-timeout option to test.py
Currently, when a process times out, it is terminated by sending it the
This can be very useful when investigating flaky tests that time out,
With these changes, passing the --abort-on-timeout command line option
Affected core subsystem(s)
This was referenced
Jan 31, 2017
That is a very good question. Enabling core files on any platform will not generate additional core files for tests that use the
The tests that are using the
I'm saying on most platforms because I'm not sure about platforms that I'm not familiar with, like AIX. Maybe @mhdawson can confirm?
On SmartOS, it's a bit different than Linux and OSX in the sense that
Now, another use case with the changes in this PR is that, when tests times out on a developer's machine, core files could be generated since not all tests run with
Thus, I would suggest to add support for a new
This way, individual developers running tests on their development machine would never have any core file generated, even if they change their OS' core file size limit, but core files would be generated when appropriate for tests running on the CI platform.
How does that sound?
I like the suggestion of --abort-on-timeout command line option for tools/test.py. I would also give us flexibility to capture/not capture the core file depending on the platform as this could be add/not added in the specific subjob for each platform.
I believe ulimit -c 0 will disabled core dumps on AIX. One ref that seems to confirm this: https://www.ibm.com/developerworks/community/blogs/KRblog/entry/aix_core_dump_facility?lang=en
Thanks for the confirmation!
My intention was to set the
Does that make sense?
@misterdjules That does make sense, I was just thinking about the easiest way to test that this actually runs on CI for all platforms might be to change the Makefile for all platforms, run CI, and then change back.
So what's the reason not to enable this on other (non-win) platforms?
Change and change back as in "commit and push" these changes to the repository? I don't think I'd want to test this change by committing/reverting, when we can test it by setting
The reason for not enabling this on other non-windows platforms is that it's not clear whether all CI machines/platforms are correctly setup for storing and cleaning up core files. AFAIK, the SmartOS machines are correctly setup with nodejs/build#492.
I wouldn't mind to enable this on all non-windows platforms, but it seems introducing it gradually doesn't have any cons and allows us to not disrupt the CI platform too much.
What do you think?
It is possible to test it. I could clone e.g the
A new temporary node-test-commit-smartos-timeout-on-abort Jenkins job was created.
It completed successfully for SmartOS 16 images, you can take a look at the console output and see that
The same tests are running for SmartOS 15 images. EDIT: these tests completed successfully too now.
Note that no test timed out though. We could introduce changes to make a test artificially time out and make sure it aborts. It seems it would be a departure from the current practice though, since AFAIK we currently don't have tests that test the tests driver.