-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
src: disable stdio buffering #7610
Conversation
CI: https://ci.nodejs.org/job/node-test-pull-request/3216/ smartos-64 stress test: https://ci.nodejs.org/job/node-stress-single-test/794/ |
Should this be back ported to v4? |
Looks like it makes the test flaky again, so at a minimum, I guess this should mark the test flaky again in |
Any chance the |
@Trott I’d say its unrelated, thanks for pinging me on this, I’ll look into it. :) |
93aea92
to
c2d15cb
Compare
Test marked FLAKY. Can I get a LGTM? |
LGTM |
1 similar comment
LGTM |
Running CI one more time mostly for confirmation of FreeBSD issue non-relevance: https://ci.nodejs.org/job/node-test-pull-request/3233/ |
Java exceptions on the pi1-raspbian-wheezy buildbots. Haven't seen this one before...
Since they were green last time, I'll land this later today unless someone disagrees. |
Disable stdio buffering, it interacts poorly with printf() calls from elsewhere in the program (e.g., any logging from V8.) Unbreaks among other things the `--trace_debug_json` switch. Undoes commit 0966ab9 ("src: force line buffering for stderr"), which in retrospect is not a proper fix. Turning on line buffering fixed a flaky test on SmartOS but the test wasn't failing on other platforms, where stderr wasn't line-buffered either. Mark the test flaky again, it failed once in a run of 333 tries on the smartos-64 buildbot. Disabling buffering should be safe even when mixed with non-blocking stdio I/O because libuv goes to great lengths to reopen the tty file descriptors and falls back to blocking I/O when that fails. PR-URL: nodejs#7610 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Rich Trott <rtrott@gmail.com>
c2d15cb
to
cfe76f2
Compare
@thealphanerd Eventually, but let's give it a little time. I'd like to see it go into one or two v6 releases first, just to check if it doesn't break anything. |
sgtm @bnoordhuis |
Disable stdio buffering, it interacts poorly with printf() calls from elsewhere in the program (e.g., any logging from V8.) Unbreaks among other things the `--trace_debug_json` switch. Undoes commit 0966ab9 ("src: force line buffering for stderr"), which in retrospect is not a proper fix. Turning on line buffering fixed a flaky test on SmartOS but the test wasn't failing on other platforms, where stderr wasn't line-buffered either. Mark the test flaky again, it failed once in a run of 333 tries on the smartos-64 buildbot. Disabling buffering should be safe even when mixed with non-blocking stdio I/O because libuv goes to great lengths to reopen the tty file descriptors and falls back to blocking I/O when that fails. PR-URL: #7610 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Rich Trott <rtrott@gmail.com>
ping @bnoordhuis |
Disable stdio buffering, it interacts poorly with printf() calls from elsewhere in the program (e.g., any logging from V8.) Unbreaks among other things the `--trace_debug_json` switch. Undoes commit 0966ab9 ("src: force line buffering for stderr"), which in retrospect is not a proper fix. Turning on line buffering fixed a flaky test on SmartOS but the test wasn't failing on other platforms, where stderr wasn't line-buffered either. Mark the test flaky again, it failed once in a run of 333 tries on the smartos-64 buildbot. Disabling buffering should be safe even when mixed with non-blocking stdio I/O because libuv goes to great lengths to reopen the tty file descriptors and falls back to blocking I/O when that fails. PR-URL: nodejs#7610 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Rich Trott <rtrott@gmail.com>
#9203 - cherry-pick to v4.x. |
Disable stdio buffering, it interacts poorly with printf() calls from elsewhere in the program (e.g., any logging from V8.) Unbreaks among other things the `--trace_debug_json` switch. Undoes commit 0966ab9 ("src: force line buffering for stderr"), which in retrospect is not a proper fix. Turning on line buffering fixed a flaky test on SmartOS but the test wasn't failing on other platforms, where stderr wasn't line-buffered either. Mark the test flaky again, it failed once in a run of 333 tries on the smartos-64 buildbot. Disabling buffering should be safe even when mixed with non-blocking stdio I/O because libuv goes to great lengths to reopen the tty file descriptors and falls back to blocking I/O when that fails. PR-URL: #7610 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Rich Trott <rtrott@gmail.com>
Disable stdio buffering, it interacts poorly with printf() calls from elsewhere in the program (e.g., any logging from V8.) Unbreaks among other things the `--trace_debug_json` switch. Undoes commit 0966ab9 ("src: force line buffering for stderr"), which in retrospect is not a proper fix. Turning on line buffering fixed a flaky test on SmartOS but the test wasn't failing on other platforms, where stderr wasn't line-buffered either. Mark the test flaky again, it failed once in a run of 333 tries on the smartos-64 buildbot. Disabling buffering should be safe even when mixed with non-blocking stdio I/O because libuv goes to great lengths to reopen the tty file descriptors and falls back to blocking I/O when that fails. PR-URL: #7610 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Rich Trott <rtrott@gmail.com>
Disable stdio buffering, it interacts poorly with printf() calls from
elsewhere in the program (e.g., any logging from V8.) Unbreaks among
other things the
--trace_debug_json
switch.Undoes commit 0966ab9 ("src: force line buffering for stderr"), which
in retrospect is not a proper fix. Turning on line buffering fixed a
flaky test on SmartOS but the test wasn't failing on other platforms,
where stderr wasn't line-buffered either.
Disabling buffering should be safe even when mixed with non-blocking
stdio I/O because libuv goes to great lengths to reopen the tty file
descriptors and falls back to blocking I/O when that fails.
R=@Trott?