Help with failed build tests #687

kasicka · 2017-06-20T09:03:05Z

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

The text was updated successfully, but these errors were encountered:

Knighton910 · 2017-07-19T15:31:35Z

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

kasicka · 2017-08-08T14:09:53Z

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 · 2017-08-08T14:53:57Z

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.

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

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 <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]>

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 <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]>

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 <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]>

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 <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]>

PR-URL: #17296 Refs: nodejs/help#687 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: James M Snell <[email protected]>

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 <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: James M Snell <[email protected]>

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 <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]>

PR-URL: #17296 Refs: nodejs/help#687 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: James M Snell <[email protected]>

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 <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: James M Snell <[email protected]>

PR-URL: #17296 Refs: nodejs/help#687 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: James M Snell <[email protected]>

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 <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: James M Snell <[email protected]>

PR-URL: #17296 Refs: nodejs/help#687 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: James M Snell <[email protected]>

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 <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: James M Snell <[email protected]>

gireeshpunathil · 2018-03-11T06:08:59Z

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

gireeshpunathil · 2018-03-13T08:48:43Z

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

kasicka · 2018-03-13T09:15:27Z

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 · 2018-03-13T10:21:31Z

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 · 2018-03-14T13:48:47Z

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

gireeshpunathil · 2018-03-15T07:37:48Z

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

gireeshpunathil · 2018-03-15T12:26:30Z

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

gireeshpunathil · 2018-03-15T12:28:29Z

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

kasicka · 2018-03-15T12:48:00Z

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

gireeshpunathil · 2018-03-15T13:05:48Z

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

Hope that explains.

gireeshpunathil · 2018-03-15T13:06:39Z

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

gireeshpunathil · 2018-03-20T11:57:07Z

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

gireeshpunathil · 2018-03-29T11:04:54Z

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

PR-URL: nodejs#17296 Refs: nodejs/help#687 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: James M Snell <[email protected]>

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 <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: James M Snell <[email protected]>

PR-URL: #17296 Backport-PR-URL: #19706 Refs: nodejs/help#687 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: James M Snell <[email protected]>

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 <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: James M Snell <[email protected]>

danbev mentioned this issue Oct 22, 2017

test: allow for different nsswitch.conf settings nodejs/node#16378

Closed

2 tasks

joyeecheung mentioned this issue Nov 25, 2017

test: mock dns lookup function in parallel tests nodejs/node#17296

Closed

4 tasks

gireeshpunathil closed this as completed Mar 13, 2018

gireeshpunathil reopened this Mar 13, 2018

gireeshpunathil mentioned this issue Mar 15, 2018

test: Incorrect assumptions on the user uid and gid nodejs/node#19371

Closed

dragonix11 mentioned this issue Mar 15, 2018

* **Scope (install, code, runtime, meta, other?)**: #1162

Closed

gireeshpunathil closed this as completed Mar 20, 2018

joyeecheung mentioned this issue Mar 30, 2018

[v8.x backport] 16390, 18547, 17296 (internet test flake fixes) nodejs/node#19706

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Help with failed build tests #687

Help with failed build tests #687

kasicka commented Jun 20, 2017 •

edited by gibfahn

Loading

Knighton910 commented Jul 19, 2017

kasicka commented Aug 8, 2017

bnoordhuis commented Aug 8, 2017

gireeshpunathil commented Mar 11, 2018

gireeshpunathil commented Mar 13, 2018

kasicka commented Mar 13, 2018

gireeshpunathil commented Mar 13, 2018

kasicka commented Mar 14, 2018 •

edited

Loading

gireeshpunathil commented Mar 15, 2018

gireeshpunathil commented Mar 15, 2018

gireeshpunathil commented Mar 15, 2018

kasicka commented Mar 15, 2018

gireeshpunathil commented Mar 15, 2018

gireeshpunathil commented Mar 15, 2018

gireeshpunathil commented Mar 20, 2018

gireeshpunathil commented Mar 29, 2018

Help with failed build tests #687

Help with failed build tests #687

Comments

kasicka commented Jun 20, 2017 • edited by gibfahn Loading

Knighton910 commented Jul 19, 2017

kasicka commented Aug 8, 2017

bnoordhuis commented Aug 8, 2017

gireeshpunathil commented Mar 11, 2018

gireeshpunathil commented Mar 13, 2018

kasicka commented Mar 13, 2018

gireeshpunathil commented Mar 13, 2018

kasicka commented Mar 14, 2018 • edited Loading

gireeshpunathil commented Mar 15, 2018

gireeshpunathil commented Mar 15, 2018

gireeshpunathil commented Mar 15, 2018

kasicka commented Mar 15, 2018

gireeshpunathil commented Mar 15, 2018

gireeshpunathil commented Mar 15, 2018

gireeshpunathil commented Mar 20, 2018

gireeshpunathil commented Mar 29, 2018

kasicka commented Jun 20, 2017 •

edited by gibfahn

Loading

kasicka commented Mar 14, 2018 •

edited

Loading