AIX CI failure: pseudo-tty/test-stderr-stdout-handle-sigwinch

[gibfahn]

• Version: master
• Platform: AIX
• Subsystem: test

pseudo-tty/test-stderr-stdout-handle-sigwinch failed the last two CI runs on the v4.x-staging branch (started by node-daily-v4.x-staging.

https://ci.nodejs.org/job/node-test-commit-aix/nodes=aix61-ppc64/4025/

Failed Build: https://ci.nodejs.org/job/node-test-commit/8092/
Failed Platform: https://ci.nodejs.org/job/node-test-commit-aix/4025
Actual Job: https://ci.nodejs.org/job/node-test-commit-aix/nodes=aix61-ppc64/4025/

not ok 1097 pseudo-tty/test-stderr-stdout-handle-sigwinch
  ---
  duration_ms: 0.211
  severity: fail
  stack: |-
  ...

cc/ @mhdawson @nodejs/platform-aix

[Fishrock123]

I still think ptys just don't work right on AIX

[gibfahn]

Possibly related pseudo-tty issues:

• AIX: Intermittent failure on pseudo-tty/test-tty-wrap #9728 pseudo-tty/test-tty-wrap - seems to need a delay on AIX
• AIX: pseudo-tty/no_dropped_stdio failures on new machine #7973 pseudo-tty/no_dropped_stdio -
• test: exclude no_interleaved_stdio test for AIX #9772, AIX: hang on pseudo-tty/no_interleaved_stdio #9765 pseudo-tty/no_interleaved_stdio -

cc/ @gireeshpunathil who has been looking at these other tests

[Fishrock123]

either that or TTYs don't work right on AIX

maybe just ignore them altogether for AIX? idk

[mhdawson]

Is this a newly backported test ? Just wondering why it would be failing consistently now versus before (if in fact 2 in a row is consistent :))

[gibfahn]

Yes, it was first added in v4.8.0:

https://github.com/nodejs/node/blob/v4.8.0/test/pseudo-tty/test-stderr-stdout-handle-sigwinch.js

[gireeshpunathil]

@Fishrock123 - other than the intermittent hang issue reported in python bug 29545 and the race condition as described in #9728, I don't see any functional issue for TTYs in AIX.

I am debugging this SIGWINCH issue to see what caused the issue.

[gireeshpunathil]

I guess the idea of the test case is to make sure the _refreshSize() of the standard streams gets called when SIGWINCH is issued on the process. This is indeed happening, consistently. What is missing again, is the race condition between the child write and the parent read.

I am in the process of experimenting by customizing the child spawn logic in the python parent to see if we can sync up the write-read logic.

[mhdawson]

Do this test fail every time on 4.x ?

[gireeshpunathil]

@mhdawson - yes, it is pretty consistent in v4.x The test passes in master, though there is a slight change in the test code (even with nullifying the change, I see the master passing).

Whereas, if I add a small delay in the v4.x case, it is consistently passing, supporting my previous update - that is, there is no new issue here, other than the race condition.

I will come up with a PR to exclude this for v4.x and work on addressing the race condition

[gireeshpunathil]

For the time exclude request raised through PR #11602