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.

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

Help with failed build tests #687

Closed
kasicka opened this issue Jun 20, 2017 · 16 comments
Closed

Help with failed build tests #687

kasicka opened this issue Jun 20, 2017 · 16 comments

Comments

@kasicka
Copy link

kasicka commented Jun 20, 2017

  • Node.js Version: 8.1.2
  • OS: RHEL 7
  • Scope (install, code, runtime, meta, other?): build
  • Module (and version) (if relevant):

Hi, I have some failed build tests on RHEL 7 that I would like to consult.

These two have been failing for v4 and v6 too:

=== release test-net-better-error-messages-port-hostname ===
Path: parallel/test-net-better-error-messages-port-hostname
assert.js:60
  throw new errors.AssertionError({
  ^
AssertionError [ERR_ASSERTION]: 'EAI_AGAIN' === 'ENOTFOUND'
    at Socket.<anonymous> (/builddir/build/BUILD/node-v8.1.2/test/parallel/test-net-better-error-messages-port-hostname.js:12:10)
    at Socket.<anonymous> (/builddir/build/BUILD/node-v8.1.2/test/common/index.js:517:15)
    at emitOne (events.js:115:13)
    at Socket.emit (events.js:210:7)
    at emitErrorNT (internal/streams/destroy.js:62:8)
    at _combinedTickCallback (internal/process/next_tick.js:102:11)
    at process._tickCallback (internal/process/next_tick.js:161:9)
Command: out/Release/node /builddir/build/BUILD/node-v8.1.2/test/parallel/test-net-better-error-messages-port-hostname.js
                                                      
=== release test-net-connect-immediate-finish ===
Path: parallel/test-net-connect-immediate-finish
assert.js:60
  throw new errors.AssertionError({
  ^
AssertionError [ERR_ASSERTION]: 'EAI_AGAIN' === 'ENOTFOUND'
    at Socket.client.once.common.mustCall (/builddir/build/BUILD/node-v8.1.2/test/parallel/test-net-connect-immediate-finish.js:32:10)
    at Socket.<anonymous> (/builddir/build/BUILD/node-v8.1.2/test/common/index.js:517:15)
    at Object.onceWrapper (events.js:316:30)
    at emitOne (events.js:115:13)
    at Socket.emit (events.js:210:7)
    at emitErrorNT (internal/streams/destroy.js:62:8)
    at _combinedTickCallback (internal/process/next_tick.js:102:11)
    at process._tickCallback (internal/process/next_tick.js:161:9)
Command: out/Release/node /builddir/build/BUILD/node-v8.1.2/test/parallel/test-net-connect-immediate-finish.js

These fail only with v8:

=== release test-util-inspect ===
Path: parallel/test-util-inspect
/builddir/build/BUILD/node-v8.1.2/test/parallel/test-util-inspect.js:85
assert.strictEqual(util.inspect(process.stdin._handle._externalStream),
                                                     ^
TypeError: Cannot read property '_externalStream' of undefined
    at Object.<anonymous> (/builddir/build/BUILD/node-v8.1.2/test/parallel/test-util-inspect.js:85:54)
    at Module._compile (module.js:569:30)
    at Object.Module._extensions..js (module.js:580:10)
    at Module.load (module.js:503:32)
    at tryModuleLoad (module.js:466:12)
    at Function.Module._load (module.js:458:3)
    at Function.Module.runMain (module.js:605:10)
    at startup (bootstrap_node.js:158:16)
    at bootstrap_node.js:575:3
Command: out/Release/node /builddir/build/BUILD/node-v8.1.2/test/parallel/test-util-inspect.js

=== release test-v8-serdes ===
Path: parallel/test-v8-serdes
assert.js:60
  throw new errors.AssertionError({
  ^
AssertionError [ERR_ASSERTION]: Missing expected exception.
    at _throws (assert.js:553:5)
    at Function.throws (assert.js:577:3)
    at Object.<anonymous> (/builddir/build/BUILD/node-v8.1.2/test/parallel/test-v8-serdes.js:98:10)
    at Module._compile (module.js:569:30)
    at Object.Module._extensions..js (module.js:580:10)
    at Module.load (module.js:503:32)
    at tryModuleLoad (module.js:466:12)
    at Function.Module._load (module.js:458:3)
    at Function.Module.runMain (module.js:605:10)
    at startup (bootstrap_node.js:158:16)
Command: out/Release/node /builddir/build/BUILD/node-v8.1.2/test/parallel/test-v8-serdes.js

I use shared zlib-1.2.7, compared to zlib-1.2.11, so maybe that fails this test:

Path: parallel/test-zlib-failed-init
assert.js:60
  throw new errors.AssertionError({
  ^
AssertionError [ERR_ASSERTION]: Missing expected exception.
    at _throws (assert.js:553:5)
    at Function.throws (assert.js:577:3)
    at Object.<anonymous> (/builddir/build/BUILD/node-v8.1.2/test/parallel/test-zlib-failed-init.js:11:8)
    at Module._compile (module.js:569:30)
    at Object.Module._extensions..js (module.js:580:10)
    at Module.load (module.js:503:32)
    at tryModuleLoad (module.js:466:12)
    at Function.Module._load (module.js:458:3)
    at Function.Module.runMain (module.js:605:10)
    at startup (bootstrap_node.js:158:16)
Command: out/Release/node /builddir/build/BUILD/node-v8.1.2/test/parallel/test-zlib-failed-init.js
@Knighton910
Copy link
Contributor

@kasicka Did you get them to pass yet? Let me know if you still need help.

@kasicka
Copy link
Author

kasicka commented Aug 8, 2017

Nope, they still fail, plus I have test-regress-GH-746 failing randomly on various archs. I can't find a log, but the test times out.

@bnoordhuis
Copy link
Member

I believe the issue that made parallel/test-util-inspect flaky was fixed recently, although that may not have made it into a release yet.

parallel/test-net-better-error-messages-port-hostname and parallel/test-net-connect-immediate-finish failing means your DNS resolver returns something unexpected for invalid hostnames. Might be a bug in the test, might be a bug in your network.

danbev added a commit to danbev/node that referenced this issue Oct 22, 2017
The motivation for this commit is that these two test fail on systems
that have different Name Service Switch configuration settings. A
concrete example of this is when using Red Hat Enterprise Linux (RHEL)
7.

If Name Service Switch is available on the operating system then it
might be configured differently (/etc/nsswitch.conf).
If the system is configured with no dns the error code will be
AI_AGAIN, but if there are more services after the dns entry, for
example some linux distributions skip a myhostname service by default
which would still produce the ENOTFOUND error.

This commit suggests checking for either ENOTFOUND or EAI_AGAIN to
accommodate systems like the ones described above. The references below
indicate that others have run, or are running, into this aswell.

Refs: nodejs#12075
Refs: nodejs/help#687
danbev added a commit to danbev/node that referenced this issue Oct 25, 2017
The motivation for this commit is that these two test fail on systems
that have different Name Service Switch configuration settings. A
concrete example of this is when using Red Hat Enterprise Linux (RHEL)
7.

If Name Service Switch is available on the operating system then it
might be configured differently (/etc/nsswitch.conf).
If the system is configured with no dns the error code will be
AI_AGAIN, but if there are more services after the dns entry, for
example some linux distributions skip a myhostname service by default
which would still produce the ENOTFOUND error.

This commit suggests checking for either ENOTFOUND or EAI_AGAIN to
accommodate systems like the ones described above. The references below
indicate that others have run, or are running, into this aswell.

Refs: nodejs#12075
Refs: nodejs/help#687
Refs: nodejs#15825
PR-URL: nodejs#16378
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
cjihrig pushed a commit to nodejs/node that referenced this issue Oct 25, 2017
The motivation for this commit is that these two test fail on systems
that have different Name Service Switch configuration settings. A
concrete example of this is when using Red Hat Enterprise Linux (RHEL)
7.

If Name Service Switch is available on the operating system then it
might be configured differently (/etc/nsswitch.conf).
If the system is configured with no dns the error code will be
AI_AGAIN, but if there are more services after the dns entry, for
example some linux distributions skip a myhostname service by default
which would still produce the ENOTFOUND error.

This commit suggests checking for either ENOTFOUND or EAI_AGAIN to
accommodate systems like the ones described above. The references below
indicate that others have run, or are running, into this aswell.

Refs: #12075
Refs: nodejs/help#687
Refs: #15825
PR-URL: #16378
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
addaleax pushed a commit to ayojs/ayo that referenced this issue Oct 26, 2017
The motivation for this commit is that these two test fail on systems
that have different Name Service Switch configuration settings. A
concrete example of this is when using Red Hat Enterprise Linux (RHEL)
7.

If Name Service Switch is available on the operating system then it
might be configured differently (/etc/nsswitch.conf).
If the system is configured with no dns the error code will be
AI_AGAIN, but if there are more services after the dns entry, for
example some linux distributions skip a myhostname service by default
which would still produce the ENOTFOUND error.

This commit suggests checking for either ENOTFOUND or EAI_AGAIN to
accommodate systems like the ones described above. The references below
indicate that others have run, or are running, into this aswell.

Refs: nodejs/node#12075
Refs: nodejs/help#687
Refs: nodejs/node#15825
PR-URL: nodejs/node#16378
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
MylesBorins pushed a commit to nodejs/node that referenced this issue Nov 16, 2017
The motivation for this commit is that these two test fail on systems
that have different Name Service Switch configuration settings. A
concrete example of this is when using Red Hat Enterprise Linux (RHEL)
7.

If Name Service Switch is available on the operating system then it
might be configured differently (/etc/nsswitch.conf).
If the system is configured with no dns the error code will be
AI_AGAIN, but if there are more services after the dns entry, for
example some linux distributions skip a myhostname service by default
which would still produce the ENOTFOUND error.

This commit suggests checking for either ENOTFOUND or EAI_AGAIN to
accommodate systems like the ones described above. The references below
indicate that others have run, or are running, into this aswell.

Refs: #12075
Refs: nodejs/help#687
Refs: #15825
PR-URL: #16378
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
MylesBorins pushed a commit to nodejs/node that referenced this issue Nov 21, 2017
The motivation for this commit is that these two test fail on systems
that have different Name Service Switch configuration settings. A
concrete example of this is when using Red Hat Enterprise Linux (RHEL)
7.

If Name Service Switch is available on the operating system then it
might be configured differently (/etc/nsswitch.conf).
If the system is configured with no dns the error code will be
AI_AGAIN, but if there are more services after the dns entry, for
example some linux distributions skip a myhostname service by default
which would still produce the ENOTFOUND error.

This commit suggests checking for either ENOTFOUND or EAI_AGAIN to
accommodate systems like the ones described above. The references below
indicate that others have run, or are running, into this aswell.

Refs: #12075
Refs: nodejs/help#687
Refs: #15825
PR-URL: #16378
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
MylesBorins pushed a commit to nodejs/node that referenced this issue Nov 28, 2017
The motivation for this commit is that these two test fail on systems
that have different Name Service Switch configuration settings. A
concrete example of this is when using Red Hat Enterprise Linux (RHEL)
7.

If Name Service Switch is available on the operating system then it
might be configured differently (/etc/nsswitch.conf).
If the system is configured with no dns the error code will be
AI_AGAIN, but if there are more services after the dns entry, for
example some linux distributions skip a myhostname service by default
which would still produce the ENOTFOUND error.

This commit suggests checking for either ENOTFOUND or EAI_AGAIN to
accommodate systems like the ones described above. The references below
indicate that others have run, or are running, into this aswell.

Refs: #12075
Refs: nodejs/help#687
Refs: #15825
PR-URL: #16378
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
joyeecheung added a commit to nodejs/node that referenced this issue Nov 28, 2017
PR-URL: #17296
Refs: nodejs/help#687
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
joyeecheung added a commit to nodejs/node that referenced this issue Nov 28, 2017
These tests should not make any DNS calls. The lookup would fail
when the DNS requests are hijacked and time out instead of erroring
out.

PR-URL: #17296
Refs: nodejs/help#687
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
addaleax pushed a commit to ayojs/ayo that referenced this issue Dec 7, 2017
The motivation for this commit is that these two test fail on systems
that have different Name Service Switch configuration settings. A
concrete example of this is when using Red Hat Enterprise Linux (RHEL)
7.

If Name Service Switch is available on the operating system then it
might be configured differently (/etc/nsswitch.conf).
If the system is configured with no dns the error code will be
AI_AGAIN, but if there are more services after the dns entry, for
example some linux distributions skip a myhostname service by default
which would still produce the ENOTFOUND error.

This commit suggests checking for either ENOTFOUND or EAI_AGAIN to
accommodate systems like the ones described above. The references below
indicate that others have run, or are running, into this aswell.

Refs: nodejs/node#12075
Refs: nodejs/help#687
Refs: nodejs/node#15825
PR-URL: nodejs/node#16378
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
MylesBorins pushed a commit to nodejs/node that referenced this issue Dec 12, 2017
PR-URL: #17296
Refs: nodejs/help#687
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
MylesBorins pushed a commit to nodejs/node that referenced this issue Dec 12, 2017
These tests should not make any DNS calls. The lookup would fail
when the DNS requests are hijacked and time out instead of erroring
out.

PR-URL: #17296
Refs: nodejs/help#687
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
MylesBorins pushed a commit to nodejs/node that referenced this issue Dec 12, 2017
PR-URL: #17296
Refs: nodejs/help#687
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
MylesBorins pushed a commit to nodejs/node that referenced this issue Dec 12, 2017
These tests should not make any DNS calls. The lookup would fail
when the DNS requests are hijacked and time out instead of erroring
out.

PR-URL: #17296
Refs: nodejs/help#687
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
MylesBorins pushed a commit to nodejs/node that referenced this issue Dec 12, 2017
PR-URL: #17296
Refs: nodejs/help#687
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
MylesBorins pushed a commit to nodejs/node that referenced this issue Dec 12, 2017
These tests should not make any DNS calls. The lookup would fail
when the DNS requests are hijacked and time out instead of erroring
out.

PR-URL: #17296
Refs: nodejs/help#687
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
@gireeshpunathil
Copy link
Member

@kasicka - please let me know if this is still outstanding.

@gireeshpunathil
Copy link
Member

closing due to inactivity, please re-open if it is still outstanding

@kasicka
Copy link
Author

kasicka commented Mar 13, 2018

I have just one test failing on master on RHEL and Rawhide, otherwise seems good or might be related to build environment.

=== release test-child-process-spawnsync-validation-errors ===
Path: parallel/test-child-process-spawnsync-validation-errors
Mismatched innerFn function calls. Expected exactly 62, actual 42.
at Object.exports.mustCall (/root/node/test/common/index.js:427:10)
at Object.expectsError (/root/node/test/common/index.js:717:18)
at Object. (/root/node/test/parallel/test-child-process-spawnsync-validation-errors.js:14:12)
at Module._compile (module.js:671:30)
at Object.Module._extensions..js (module.js:682:10)
at Module.load (module.js:582:32)
at tryModuleLoad (module.js:522:12)
at Function.Module._load (module.js:514:3)
at Function.Module.runMain (module.js:712:10)
Command: out/Release/node /root/node/test/parallel/test-child-process-spawnsync-validation-errors.js

@gireeshpunathil
Copy link
Member

is it consistently failing for you? I am unable to reproduce. Few suggestions:

  • please run as non-root
  • there are a number of (more than 100) independent pass(..) and fail(...) calls. Please reduce the test case by incrementally removing them - to identify which call is failing.

@kasicka
Copy link
Author

kasicka commented Mar 14, 2018

Right, fails only in container.. also upon investigating, the !common.isWindows part doesn't pass in container

@gireeshpunathil
Copy link
Member

thanks. Container spec please? I will attempt a reproduce.

@gireeshpunathil
Copy link
Member

what does node -e 'console.log(process.getuid())' print for you? 0?

@gireeshpunathil
Copy link
Member

and node -e 'console.log(process.getgid())'

@kasicka
Copy link
Author

kasicka commented Mar 15, 2018

Just plain Fedora Rawhide container.
Yes, both are 0, which explains failed test, but shouldn't it fail on v9 and v8 too?

@gireeshpunathil
Copy link
Member

thanks for the confirmation, the test has changed recently, though I did not check the exact nature of change.

Hope that explains.

@gireeshpunathil
Copy link
Member

@kasicka - feel free to come up with a PR to fix it. :)

@gireeshpunathil
Copy link
Member

closing as answered and explained, the identified issue tracked under nodejs/node#19371 .

@gireeshpunathil
Copy link
Member

@kasicka - fyi, this is fixed via nodejs/node#19554

joyeecheung added a commit to joyeecheung/node that referenced this issue Mar 30, 2018
PR-URL: nodejs#17296
Refs: nodejs/help#687
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
joyeecheung added a commit to joyeecheung/node that referenced this issue Mar 30, 2018
These tests should not make any DNS calls. The lookup would fail
when the DNS requests are hijacked and time out instead of erroring
out.

PR-URL: nodejs#17296
Refs: nodejs/help#687
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
gibfahn pushed a commit to nodejs/node that referenced this issue Apr 11, 2018
PR-URL: #17296
Backport-PR-URL: #19706
Refs: nodejs/help#687
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
gibfahn pushed a commit to nodejs/node that referenced this issue Apr 11, 2018
These tests should not make any DNS calls. The lookup would fail
when the DNS requests are hijacked and time out instead of erroring
out.

PR-URL: #17296
Backport-PR-URL: #19706
Refs: nodejs/help#687
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants