Closed joyeecheung closed 5 years ago
Renamed issue, since we're still in 2018-08 (AFAICT, I did take a nap, both I don't feel like it was that long 😴)
RE: addons/stringbytes-external-exceed-max/test-stringbytes-external-exceed-max-by-1-binary
[iojs@test-digitalocean-freebsd11-x64-2 /usr/home/iojs/build/workspace/node-test-commit-freebsd/nodes/freebsd11-x64]$ ./node -p "require('os').totalmem()"
2107195392
So is seems like node
knows how to check memory size, and those machines have 2GB which is more than the cutoff > 0x70000000; /* 1.75 Gb */
.
.
.
Just before hitting submit I run this:
[iojs@test-digitalocean-freebsd11-x64-2 /usr/home/iojs/build/workspace/node-test-commit-freebsd/nodes/freebsd11-x64]$ ./node -p "require('os').freemem()"
19468288
So that might be a problem.
So is seems like
node
knows how to check memory size, and those machines have 2GB which is more than the cutoff> 0x70000000; /* 1.75 Gb */
That cut-off was arrived at through experimentation and is a little bit like when we come across seemingly-arbitrary values in setTimeout()
.
If the test didn't require an addon (and it didn't used to, but we switched to an addon for reliability, I think?), then maybe it could be moved to pummel
. Is it possible to move this test and the other stringbytes
tests to pummel
somehow? That should also please the "our tests take too long to run" folks because...these tests can take a while to run on some platforms.
AFAICT it not supposed to be a pummel test. It's there to assert kStringMaxLength
behaviour. We could move it to v8-updates
tough...
AFAICT it not supposed to be a pummel test.
I figured pummel
is for tests that require a lot of resources but I see there's a bit of a more specific description in the test README. So if v8-updates
seems a better place for it, that's fine by me too, of course.
The problem with addons/stringbytes-external-exceed-max/test-stringbytes-external-exceed-max-by-1-binary
is that it crashed on digital ocean freebsd11 nodes with signal 9, even though if the memory is not enough it should've thrown proper errors - also the line maxString = undefined
there does not work as a GC hint, @refack discovered that calling the v8 gc helper explicitly could make the crash go away (but then even if GC does not work it should not have crashed).
gc trace when failing: https://www.irccloud.com/pastebin/FI3zgCwR/
gc trace when passing: https://www.irccloud.com/pastebin/059SqSBt/
gc trace with explicit global.gc()
calls:
https://www.irccloud.com/pastebin/zMF1YpIa/
The Cannot rebase: You have unstaged changes.
seems to be caused by EOL autofixes in git gone wrong. deps/v8/third_party/jinja2/LICENSE
uses CRLF and looks like git clean -fdx
run by the git plugin in jenkins caused inconsistency in the working directory.
and looks like git clean -fdx run by the git plugin in jenkins caused inconsistency in the working directory.
It's more like the default git
behaviour (in conjunction with recursive application of .gitattributes
) is to mark those files as Modified
so that they will be committed with LF
line endings.
Best solution I've found is to set the CI worker to:
git config --global --bool core.autocrlf false
git config --global --bool core.safecrlf false
Which makes sense, in that CI workers should not change files in any way
FYI re FreeBSD 11, we upgraded from 11.0 to 11.2 which may explain the difference in system inspection
BTW, looks like jinja2
is only committed by us, it's in v8's DEPS file but they don't commit that directory (it's probably fetched by gclient)
@refack @joyeecheung autocrlf
should not be changed in the Windows machines, we want to ensure new contributors can compile with a default installation of Git (we already ask for the Unix tools, but the less of those little details the better and some people might not want to change it). If possible, please use https://github.com/nodejs/node/blob/master/.gitattributes to specify that that file is always CRLF.
Produced with
ncu-ci walk pr --stats
, counting tests that failed more than 1 PRPotential flaky tests
https://github.com/nodejs/node/issues/22317
https://github.com/nodejs/node/issues/15985
https://github.com/nodejs/node/issues/21425
???
Build issues:
git EOL autofix issues, see https://github.com/nodejs/reliability/issues/12#issuecomment-412683325
https://github.com/nodejs/build/issues/1443
libicui18n.a compilation errors, e.g. https://ci.nodejs.org/job/node-test-commit-smartos/nodes=smartos17-64/19373/console should be fixed already
Errors during compiling libopenssl.a e.g. https://ci.nodejs.org/job/node-test-commit-custom-suites-freestyle/15/console should be fixed already
Jenkins script errors, should be fixed
???