-
Notifications
You must be signed in to change notification settings - Fork 30k
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
LTO enabled built node
binary doesn't exit
#40368
Comments
Problem exists all the way back to Node.js 16.1.0. Node.js 16.0.0 fails to compile with
|
Little off topic, but would it make sense to have LTO label? |
This issue only happens when Node.js is configured with This debugging session contains details about this issue and for those how don't want to read through all of that the summary is that GCC LTO was generating some incorrect code (not blaming GCC, or anyone else for that matter) which was causing this issue. After some investigating the issue pointed me to libuv/libuv#2588 and adding |
This commit turns on `-fno-strict-aliasing` in libuv. Fixes: nodejs#40368 Refs: libuv/libuv#1230
This commit turns on `-fno-strict-aliasing` in libuv. Fixes: nodejs#40368 Refs: libuv/libuv#1230
This commit turns on `-fno-strict-aliasing` in libuv. Fixes: #40368 Refs: libuv/libuv#1230 PR-URL: #40631 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Santiago Gimeno <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Voltrex <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
This commit turns on `-fno-strict-aliasing` in libuv. Fixes: #40368 Refs: libuv/libuv#1230 PR-URL: #40631 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Santiago Gimeno <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Voltrex <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
This commit turns on `-fno-strict-aliasing` in libuv. Fixes: #40368 Refs: libuv/libuv#1230 PR-URL: #40631 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Santiago Gimeno <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Voltrex <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
This commit turns on `-fno-strict-aliasing` in libuv. Fixes: #40368 Refs: libuv/libuv#1230 PR-URL: #40631 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Santiago Gimeno <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Voltrex <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
This commit turns on `-fno-strict-aliasing` in libuv. Fixes: #40368 Refs: libuv/libuv#1230 PR-URL: #40631 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Santiago Gimeno <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Voltrex <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
This commit turns on `-fno-strict-aliasing` in libuv. Fixes: #40368 Refs: libuv/libuv#1230 PR-URL: #40631 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Santiago Gimeno <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Voltrex <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
This commit turns on `-fno-strict-aliasing` in libuv. Fixes: #40368 Refs: libuv/libuv#1230 PR-URL: #40631 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Santiago Gimeno <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Voltrex <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
Version
v17.0.0-pre
Platform
Linux b4436f7227be 4.18.0-240.10.1.el8_3.x86_64 #1 SMP Wed Dec 16 03:30:52 EST 2020 x86_64 GNU/Linux (the gcc:11 container)
Subsystem
No response
What steps will reproduce the bug?
How often does it reproduce? Is there a required condition?
Every time
What is the expected behavior?
Node.js prints the contents of
process.versions
and exits.What do you see instead?
Contents of
process.versions
is printed but the process does not exit.Additional information
Doesn't happen with regular non-LTO builds.
I've been testing inside the gcc:11 container (following the steps in https://github.com/nodejs/node/blob/master/.github/workflows/daily.yml). Please note that the build is succeeds but the GitHub workflow doesn't attempt to run the built binary (or run any tests). Interestingly the
repl
will exit but running scripts or tests does not.Use of
ninja
isn't the issue -- the problem replicates if building withmake
.Earlier versions of gcc can't build Node.js with LTO enabled (see #38570).
AFAICT this also occurs with the current v16.x-staging (e.g. before the V8 9.4 update). I haven't gone back any further yet.
The text was updated successfully, but these errors were encountered: