Skip to content
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.

Sign up for GitHub

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

Jump to bottom

investigate flaky sequential/test-regress-GH-897 on Raspberry Pi #10073

Closed
Trott opened this issue Dec 1, 2016 · 1 comment
Closed

investigate flaky sequential/test-regress-GH-897 on Raspberry Pi #10073

Trott opened this issue Dec 1, 2016 · 1 comment
Labels
arm Issues and PRs related to the ARM platform. test Issues and PRs related to the tests. timers Issues and PRs related to the timers subsystem / setImmediate, setInterval, setTimeout.

Comments

@Trott
Copy link
Member

Trott commented Dec 1, 2016

https://ci.nodejs.org/job/node-test-binary-arm/4936/RUN_SUBSET=6,label=pi1-raspbian-wheezy/console

not ok 177 sequential/test-regress-GH-897
  ---
  duration_ms: 2.464
  severity: fail
  stack: |-
    
    assert.js:85
      throw new assert.AssertionError({
      ^
    AssertionError: timer fired after 104 ms
        at Timeout.<anonymous> (/home/iojs/build/workspace/node-test-binary-arm/test/sequential/test-regress-GH-897.js:16:10)
        at Timeout._onTimeout (/home/iojs/build/workspace/node-test-binary-arm/test/common.js:416:15)
        at ontimeout (timers.js:365:14)
        at tryOnTimeout (timers.js:237:5)
        at Timer.listOnTimeout (timers.js:207:5)
@Trott Trott added arm Issues and PRs related to the ARM platform. test Issues and PRs related to the tests. labels Dec 1, 2016
@mscdex mscdex added the timers Issues and PRs related to the timers subsystem / setImmediate, setInterval, setTimeout. label Dec 1, 2016
@mhdawson mhdawson mentioned this issue Dec 5, 2016
Closed
@mhdawson mhdawson mentioned this issue Dec 14, 2016
Closed
@Trott
Copy link
Member Author

Trott commented Jan 19, 2017

Failed again today:

https://ci.nodejs.org/job/node-test-binary-arm/5976/RUN_SUBSET=5,label=pi1-raspbian-wheezy/console

not ok 186 sequential/test-regress-GH-897
  ---
  duration_ms: 2.148
  severity: fail
  stack: |-
    
    assert.js:85
      throw new assert.AssertionError({
      ^
    AssertionError: timer fired after 100 ms
        at Timeout.<anonymous> (/home/iojs/build/workspace/node-test-binary-arm/test/sequential/test-regress-GH-897.js:16:10)
        at Timeout._onTimeout (/home/iojs/build/workspace/node-test-binary-arm/test/common.js:446:15)
        at ontimeout (timers.js:365:14)
        at tryOnTimeout (timers.js:237:5)
        at Timer.listOnTimeout (timers.js:207:5)
  ...

Trott added a commit to Trott/io.js that referenced this issue Jan 19, 2017
@Trott
test: fix flaky test-regress-nodejsGH-897
65d0489 
Even after being moved to `sequential` in
1ce05ad, `test-regress-nodejsGH-897` still
was occasionally flaky on Raspberry Pi devices on CI.

The test is especially sensitive to resource constraints. It failed
reliably on my laptop if I moved it to `parallel` and ran 32 competing
node test processes. Even for a flaky test, that's unusually low. I
typically don't see problems, even for flaky tests, until I get up to
around four times that number.

On a Raspberry Pi, of course, that sensitivity to resource constraints
will manifest much sooner.

This change checks the order of timers firing, rather than the duration
before a timer is fired. This eliminates the sensitivity to resource
constraints. The test can now be moved back to `parallel`. I am able to
run many copies of the test simultaneously without seeing test failures.

Fixes: nodejs#10073
@Trott Trott mentioned this issue Jan 19, 2017
Closed
3 tasks
@Trott Trott closed this as completed in 80c72c6 Jan 23, 2017
italoacasas pushed a commit to italoacasas/node that referenced this issue Jan 25, 2017
@Trott @italoacasas
test: fix flaky test-regress-nodejsGH-897
09f2831 
Even after being moved to `sequential` in
1ce05ad, `test-regress-nodejsGH-897` still
was occasionally flaky on Raspberry Pi devices on CI.

The test is especially sensitive to resource constraints. It failed
reliably on my laptop if I moved it to `parallel` and ran 32 competing
node test processes. Even for a flaky test, that's unusually low. I
typically don't see problems, even for flaky tests, until I get up to
around four times that number.

On a Raspberry Pi, of course, that sensitivity to resource constraints
will manifest much sooner.

This change checks the order of timers firing, rather than the duration
before a timer is fired. This eliminates the sensitivity to resource
constraints. The test can now be moved back to `parallel`. I am able to
run many copies of the test simultaneously without seeing test failures.

PR-URL: nodejs#10903
Fixes: nodejs#10073
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
italoacasas pushed a commit to italoacasas/node that referenced this issue Jan 27, 2017
@Trott @italoacasas
test: fix flaky test-regress-nodejsGH-897
3ce9681 
Even after being moved to `sequential` in
1ce05ad, `test-regress-nodejsGH-897` still
was occasionally flaky on Raspberry Pi devices on CI.

The test is especially sensitive to resource constraints. It failed
reliably on my laptop if I moved it to `parallel` and ran 32 competing
node test processes. Even for a flaky test, that's unusually low. I
typically don't see problems, even for flaky tests, until I get up to
around four times that number.

On a Raspberry Pi, of course, that sensitivity to resource constraints
will manifest much sooner.

This change checks the order of timers firing, rather than the duration
before a timer is fired. This eliminates the sensitivity to resource
constraints. The test can now be moved back to `parallel`. I am able to
run many copies of the test simultaneously without seeing test failures.

PR-URL: nodejs#10903
Fixes: nodejs#10073
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
italoacasas pushed a commit to italoacasas/node that referenced this issue Jan 30, 2017
@Trott @italoacasas
test: fix flaky test-regress-nodejsGH-897
9d5170f 
Even after being moved to `sequential` in
1ce05ad, `test-regress-nodejsGH-897` still
was occasionally flaky on Raspberry Pi devices on CI.

The test is especially sensitive to resource constraints. It failed
reliably on my laptop if I moved it to `parallel` and ran 32 competing
node test processes. Even for a flaky test, that's unusually low. I
typically don't see problems, even for flaky tests, until I get up to
around four times that number.

On a Raspberry Pi, of course, that sensitivity to resource constraints
will manifest much sooner.

This change checks the order of timers firing, rather than the duration
before a timer is fired. This eliminates the sensitivity to resource
constraints. The test can now be moved back to `parallel`. I am able to
run many copies of the test simultaneously without seeing test failures.

PR-URL: nodejs#10903
Fixes: nodejs#10073
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
italoacasas pushed a commit to italoacasas/node that referenced this issue Jan 30, 2017
@Trott @italoacasas
test: fix flaky test-regress-nodejsGH-897
1b8c238 
Even after being moved to `sequential` in
1ce05ad, `test-regress-nodejsGH-897` still
was occasionally flaky on Raspberry Pi devices on CI.

The test is especially sensitive to resource constraints. It failed
reliably on my laptop if I moved it to `parallel` and ran 32 competing
node test processes. Even for a flaky test, that's unusually low. I
typically don't see problems, even for flaky tests, until I get up to
around four times that number.

On a Raspberry Pi, of course, that sensitivity to resource constraints
will manifest much sooner.

This change checks the order of timers firing, rather than the duration
before a timer is fired. This eliminates the sensitivity to resource
constraints. The test can now be moved back to `parallel`. I am able to
run many copies of the test simultaneously without seeing test failures.

PR-URL: nodejs#10903
Fixes: nodejs#10073
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
MylesBorins pushed a commit that referenced this issue Mar 8, 2017
@Trott @MylesBorins
test: fix flaky test-regress-GH-897
8ecd878 
Even after being moved to `sequential` in
1ce05ad, `test-regress-GH-897` still
was occasionally flaky on Raspberry Pi devices on CI.

The test is especially sensitive to resource constraints. It failed
reliably on my laptop if I moved it to `parallel` and ran 32 competing
node test processes. Even for a flaky test, that's unusually low. I
typically don't see problems, even for flaky tests, until I get up to
around four times that number.

On a Raspberry Pi, of course, that sensitivity to resource constraints
will manifest much sooner.

This change checks the order of timers firing, rather than the duration
before a timer is fired. This eliminates the sensitivity to resource
constraints. The test can now be moved back to `parallel`. I am able to
run many copies of the test simultaneously without seeing test failures.

PR-URL: #10903
Fixes: #10073
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
MylesBorins pushed a commit that referenced this issue Mar 9, 2017
@Trott @MylesBorins
test: fix flaky test-regress-GH-897
e59697c 
Even after being moved to `sequential` in
1ce05ad, `test-regress-GH-897` still
was occasionally flaky on Raspberry Pi devices on CI.

The test is especially sensitive to resource constraints. It failed
reliably on my laptop if I moved it to `parallel` and ran 32 competing
node test processes. Even for a flaky test, that's unusually low. I
typically don't see problems, even for flaky tests, until I get up to
around four times that number.

On a Raspberry Pi, of course, that sensitivity to resource constraints
will manifest much sooner.

This change checks the order of timers firing, rather than the duration
before a timer is fired. This eliminates the sensitivity to resource
constraints. The test can now be moved back to `parallel`. I am able to
run many copies of the test simultaneously without seeing test failures.

PR-URL: #10903
Fixes: #10073
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
arm Issues and PRs related to the ARM platform. test Issues and PRs related to the tests. timers Issues and PRs related to the timers subsystem / setImmediate, setInterval, setTimeout.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

test: fix flaky test-regress-GH-897 Trott/io.js
2 participants
@mscdex @Trott