Repository navigation
Compilation broken on win-vs2017 (only tested on Node.js14) #1237
Description
Looks like the CI has been broken since Nov 11th:
https://ci.nodejs.org/job/node-test-node-addon-api-new/nodes=win-vs2017/6656/console
Failure is:
thunking_manual.cc
object_deprecated.cc
win_delay_load_hook.cc
binding-swallowexcept.cc
error.cc
win_delay_load_hook.cc
Creating library C:\workspace\node-test-node-addon-api-new\nodes\win-vs2017\node-addon-api\test\build\Release\binding_swallowexcept.lib and object C:\workspace\node-test-node-addon-api-new\nodes\win-vs2017\node-addon-api\test\build\Release\binding_swallowexcept.exp
binding_swallowexcept.vcxproj -> C:\workspace\node-test-node-addon-api-new\nodes\win-vs2017\node-addon-api\test\build\Release\\binding_swallowexcept.node
binding-swallowexcept.cc
error.cc
win_delay_load_hook.cc
Creating library C:\workspace\node-test-node-addon-api-new\nodes\win-vs2017\node-addon-api\test\build\Release\binding_swallowexcept_noexcept.lib and object C:\workspace\node-test-node-addon-api-new\nodes\win-vs2017\node-addon-api\test\build\Release\binding_swallowexcept_noexcept.exp
binding_swallowexcept_noexcept.vcxproj -> C:\workspace\node-test-node-addon-api-new\nodes\win-vs2017\node-addon-api\test\build\Release\\binding_swallowexcept_noexcept.node
gyp ERR! build error
gyp ERR! stack Error: `C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\MSBuild.exe` failed with exit code: 1
gyp ERR! stack at ChildProcess.onExit (C:\workspace\node-test-node-addon-api-new\nodes\win-vs2017\node-v14.21.1-win-x64\node_modules\npm\node_modules\node-gyp\lib\build.js:194:23)
gyp ERR! stack at ChildProcess.emit (events.js:400:28)
gyp ERR! stack at Process.ChildProcess._handle.onexit (internal/child_process.js:285:12)
gyp ERR! System Windows_NT 6.3.9600
gyp ERR! command "C:\\workspace\\node-test-node-addon-api-new\\nodes\\win-vs2017\\node-v14.21.1-win-x64\\node.exe" "C:\\workspace\\node-test-node-addon-api-new\\nodes\\win-vs2017\\node-v14.21.1-win-x64\\node_modules\\npm\\node_modules\\node-gyp\\bin\\node-gyp.js" "rebuild" "-C" "test"
gyp ERR! cwd C:\workspace\node-test-node-addon-api-new\nodes\win-vs2017\node-addon-api\test
gyp ERR! node -v v14.21.1
gyp ERR! node-gyp -v v5.1.0
gyp ERR! not ok
npm ERR! Test failed. See above for more details.
Build step 'Conditional steps (multiple)' marked build as failure
Collecting metadata...
Metadata collection done.
Notifying upstream projects of job completion
Finished: FAILURE
Activity
mhdawson commentedon Nov 22, 2022
It's not obvious that anything was committed to node-addon-api around that time.
It does not look like 14.x changed either (last release was 4 nov).
StefanStojanovic commentedon Nov 24, 2022
Looks like the real issue, the error is further above in the log
mhdawson commentedon Nov 24, 2022
@richardlau just wondering if any of the windows auto update you mentioned were around the time we started to see failures in the job. My guess is not but better to ask.
mhdawson commentedon Nov 24, 2022
@StefanStojanovic thanks for info above.
Looking at the blame for line 5351, it does not seem to have been modified recently.
Jun 13, 2020
implement optional function callback
details::CallJsWrapper<ContextType, DataType, decltype(CallJs), CallJs>(
env, jsCallback, context, data);
And the last change to napi-inl.h and napi.h was Oct14, 2022 so it does not seem liek the code itself was modified around the time the failure started.
mhdawson commentedon Nov 24, 2022
Looks like the errors start at
.\typed_threadsafe_function\typed_threadsafe_function_ctx.cc).That was recently modified ! - #1201
@JckXia since you probably have the most context any chance you could take a look?
richardlau commentedon Nov 24, 2022
It does looks the machine was updated/rebooted on the 11 Nov (to determine, look at the build history for the machine(s) and any failing windows-update-reboot jobs (failing jobs generally mean the machines were rebooted)):
which led to Python errors (e.g. https://ci.nodejs.org/job/node-test-node-addon-api-new/nodes=win-vs2017/6636/console) until I rolled back and pinned Python on those machines a week ago and then the build was failing with the error in #1237 (comment).
JckXia commentedon Nov 24, 2022
@mhdawson Looking into it now. From what I understand build https://ci.nodejs.org/job/node-test-node-addon-api-new/nodes=win-vs2017/6640/console is the earliest appearance of the error related to
typed_threadsafe_function_ctx.cc, which was scheduled to run on Nov 18th, and before that there are some python errors masking the issueMy PR #1201 (comment) looked like it was merged on Nov-15th with no apparent build issues on the PR pipeline. Just curious but do we not include
win-vs2017as one of the PR pipeline stages? Will dig deeper but it was probably related to the test I've added.JckXia commentedon Nov 25, 2022
I think the issue may be because of the way I am instantiating
TSFNand using theTSFN::Newfor that test. For the test, I am testing variousTSFN::Newoverloads. A deeper look intoTSFN::Newshows that it passesCallJsInternalinto the C NAPInapi_create_threadsafe_function.Digging a bit more into the pipeline error messages, I saw this particular error that was interesting:
c:\workspace\node-test-node-addon-api-new\nodes\win-vs2017\node-addon-api\napi-inl.h(5352): error C2770: invalid explicit template argument(s) for 'std::enable_if<call!=,void>::type Napi::details::CallJsWrapper(napi_env,napi_value,void *,void *)' (compiling source file ..\typed_threadsafe_function\typed_threadsafe_function_ctx.cc) [C:\workspace\node-test-node-addon-api-new\nodes\win-vs2017\node-addon-api\test\build\binding.vcxproj]I did some research into C2770 but only have a vague idea of what it is. Perhaps one of, or various
TSFN::Newinvocations in the test https://github.com/nodejs/node-addon-api/pull/1201/files violated this compiler rule and it's bugging out. Or perhaps my originalTSFNinstantiations weren't correct for this particular compiler I think my next step is to reproduce this locally and do more digging into C2770.JckXia commentedon Nov 28, 2022
I was able to reproduce this issue locally using visual studio 2019 + node v12. I believe the issue might be MSVC having trouble deducting the type of
callto be used with std::enable_if. I updatednapi-inl.hwith a workaround that seems to resolve this issue locally. https://github.com/nodejs/node-addon-api/pull/1242/filesNickNaso commentedon Jan 13, 2023
I think that we can close the issue because it has been solved with the following PRs: