-
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
[8.x] deps: V8: backport 49712d8a from upstream #21334
Conversation
deps/v8/src/wasm/wasm-js.cc
Outdated
Local<Value> ffi = args[1]; | ||
i::Handle<i::Object> first_arg = Utils::OpenHandle(*first_arg_value); | ||
if (!first_arg->IsJSObject()) { | ||
>>>>>>> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like some merge conflicts sneaked in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yikes. Fixed.
2da030f
to
eeab6c1
Compare
Fixed the merge conflict. This didn't land cleanly on CI: https://ci.nodejs.org/job/node-test-pull-request/15511/ |
@nodejs/build @mhdawson the V8-CI seems to be hitting infra issues AFAICT. Any ideas?
|
|
@mhdawson @nodejs/build ping. Several V8 back-port are blocked because of this. |
It's not happening on all V8 backports though. Maybe it's only happening to v8.x backports? |
The compiler level used on LinuxOne (s390x), ppcle Linux and AIX is based on the version of Node.js (i.e., >9): https://github.com/nodejs/build/blob/master/jenkins/scripts/select-compiler.sh |
There seem to be a few issues. I fixed IBM platform specific ones related to changes made to build with GN. But those were not what was reported here. opened nodejs/build#1370 as it seems to fail for other reasons on x86 for 10.x |
It seems to fail on V8.x without any other changes, @mmarchini confirmed it fails the same for V8.x-staging. |
Cleaned the workspace, if that still fails then my next guess is that something landed in v8.x v8.x-staging which broke it. Run on v8.x after cleaning workspace: https://ci.nodejs.org/job/node-test-commit-v8-linux/1456/ |
@richardlau I don't know what you are trying to point out? It fails across the board for v8.x including x86. |
Relaunched V8-CI: https://ci.nodejs.org/view/All/job/node-test-commit-v8-linux/1457/ |
Build to see if it passed on 6.x or not https://ci.nodejs.org/job/node-test-commit-v8-linux/1458/ It still failed on 8.x. If it passes on 6.x then I think its something in the 8.x line. . |
It failed on my PR branch. Here's a build of the |
Workspace clean then build on 6.x - https://ci.nodejs.org/job/node-test-commit-v8-linux/1460/ |
My apologies, I didn't spot that |
All failed. |
Failed for a different reason on 6.x. I'm wondering if it has to do with the google tooling required to build. @MylesBorins when was the last time these worked on 6.x and 8.x? |
|
we had V8 ci pass on 8.x-staging recently https://ci.nodejs.org/view/All/job/node-test-commit-v8-linux/1426/ |
@mmarchini mentioned his test run was on OSX not linux, so not necessary confirmation one way or the other. |
Same failures while running tests on another CI machine: I'm working on it, but might take some time to track down and fix this one. |
I was able to reproduce in an Ubuntu 16.04 x64 VM on my computer, so this is definitely not a problem with our infrastructure. Let me see if I can find when this started to happen. |
The other thing I noticed was it looks like the passing builds (10.x and later) use g++ while the failing ones use clang (8.x). Not sure why what would be the case. Also the failures on ppc and s390 look different, have asked @mmallick-ca to take a look at what might be going on there. Sounds like gclient sync is not pulling in something that is required. |
At this point I'll wait to see what @mmarchini figures out before spending any more time on this. |
New V8-CI: https://ci.nodejs.org/view/All/job/node-test-commit-v8-linux/1496/ @nodejs/lts @nodejs/v8-update this backport needs an LGTM before it can land. |
Original commit message: [wasm] Call AsyncInstantiate directly when instantiating a module object WebAssembly.instantiate is polymorphic, it can either take a module object as parameter, or a buffer source which should be compiled first. To share code between the two implementations, the module object was first passed to a promise (i.e. which is the result of compilation). However, passing the module object to a promise has a side effect if the module object has a then function. To avoid this side effect I remove this code sharing and call AsyncInstantiate directly in case the parameter is a module object. [email protected] Bug: chromium:836141 Change-Id: I67b76d0d7761c5aeb2cf1deda45b6842e494eed4 Reviewed-on: https://chromium-review.googlesource.com/1025774 Reviewed-by: Michael Starzinger <[email protected]> Commit-Queue: Andreas Haas <[email protected]> Cr-Commit-Position: refs/heads/master@{nodejs#52755}
eeab6c1
to
915ec4f
Compare
@nodejs/lts @nodejs/v8-update another ping. This needs an LGTM. A rubber stamp would do. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rubber stamp
|
Ooops, I intended to add the above to #21558. |
landed in 2afc05e |
Original commit message: [wasm] Call AsyncInstantiate directly when instantiating a module object WebAssembly.instantiate is polymorphic, it can either take a module object as parameter, or a buffer source which should be compiled first. To share code between the two implementations, the module object was first passed to a promise (i.e. which is the result of compilation). However, passing the module object to a promise has a side effect if the module object has a then function. To avoid this side effect I remove this code sharing and call AsyncInstantiate directly in case the parameter is a module object. [email protected] Bug: chromium:836141 Change-Id: I67b76d0d7761c5aeb2cf1deda45b6842e494eed4 Reviewed-on: https://chromium-review.googlesource.com/1025774 Reviewed-by: Michael Starzinger <[email protected]> Commit-Queue: Andreas Haas <[email protected]> Cr-Commit-Position: refs/heads/master@{#52755} PR-URL: #21334 Reviewed-By: Michaël Zasso <[email protected]>
Original commit message: [wasm] Call AsyncInstantiate directly when instantiating a module object WebAssembly.instantiate is polymorphic, it can either take a module object as parameter, or a buffer source which should be compiled first. To share code between the two implementations, the module object was first passed to a promise (i.e. which is the result of compilation). However, passing the module object to a promise has a side effect if the module object has a then function. To avoid this side effect I remove this code sharing and call AsyncInstantiate directly in case the parameter is a module object. [email protected] Bug: chromium:836141 Change-Id: I67b76d0d7761c5aeb2cf1deda45b6842e494eed4 Reviewed-on: https://chromium-review.googlesource.com/1025774 Reviewed-by: Michael Starzinger <[email protected]> Commit-Queue: Andreas Haas <[email protected]> Cr-Commit-Position: refs/heads/master@{#52755} PR-URL: #21334 Reviewed-By: Michaël Zasso <[email protected]>
Original commit message:
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesThis effects
9.x
as well, but I expect it is not worthwhile fixing there at this point./cc @nodejs/v8-update
V8-CI: https://ci.nodejs.org/view/All/job/node-test-commit-v8-linux/1425/