-
-
Notifications
You must be signed in to change notification settings - Fork 8
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
feat: node 20.14.0 #37
base: main
Are you sure you want to change the base?
Conversation
@Shogan @sean-stage @Rob3rtS could someone of you give a try to this please? |
@axi92 working on this |
This comment was marked as resolved.
This comment was marked as resolved.
This reverts commit e30fd1f.
I just tried the patch: The issue is the same as in node:internal/errors:541 TypeError [ERR_INVALID_ARG_TYPE]: The "paths[0]" argument must be of type string. Received undefined Node.js v20.14.0 When I run the .exe with e.g. myTest.exe app.js then the exe executes the given app.js instead of the internal embedded code when starting myTest.exe only I get the above error |
@matthias-heller Same for the 18.20.2? Could you test that too please? |
I have a feel that's something happening only with windows exec as I'm not able to reproduce it with linux |
@Shogan I know you also got that issue, did you tested the win exe too? |
I have the issue with linux also. 18.20.2 I can't test as the effort in our environment would be quite big |
@matthias-heller Are you able to provide a minimal script that once packaged reproduces the issue? Because I'm not able to reproduce this |
@robertsLando: Yes seems so. with your binary at least it is build again node:internal/errors:541 TypeError [ERR_INVALID_ARG_TYPE]: The "paths[0]" argument must be of type string. Received undefined I'll have a look at my build environment as next step first |
@robertsLando: Build issue is fixed and I at least now have the same situation with your binary and my own build one. While Building: While Running the build binary: Does this help you something?
if (expandArgv1 && process.argv[1] &&
!StringPrototypeStartsWith(process.argv[1], '-') &&
process.argv[1] !== 'PKG_DUMMY_ENTRYPOINT') {
// Expand process.argv[1] into a full path.
log("Expand process.argv[1] into a full path.")
const path = require('path');
process.argv.forEach((arg, index) => {
log(`argv[${index}] = ${arg}`);
});
try {
mainEntry = path.resolve(process.argv[1]);
process.argv[1] = mainEntry;
log("After updating process.argv[1]")
process.argv.forEach((arg, index) => {
log(`argv[${index}] = ${arg}`);
});
} catch {
// Continue regardless of error.
}
}
|
One more hint prepareMainThreadExecution returns undefined when running the .exe |
What is a little strange is: I added some more traces: I run the application and this is what I see Thu Jul 25 2024 11:07:31 GMT+0200 (GMT+02:00) - enter pkg.js:main But when I look into the exe I don't understand why this is happening:
var PAYLOAD_POSITION = '42007552 ' | 0;
var PAYLOAD_SIZE = '944 ' | 0;
var PRELUDE_POSITION = '42008496 ' | 0;
var PRELUDE_SIZE = '74570 ' | 0;
if (!PRELUDE_POSITION) {
log('no prelude - remove entrypoint from argv[1]');
process.argv.splice(1, 1);
process.argv.forEach((arg, index) => {
log(`argv[${index}] = ${arg}`);
});
return { undoPatch: true };
}
But even with the stuff from the executable the if condition evaluates to true when running the application. I have another trace when reading the prelude and this is never called |
Could I ask you what it was?
Wow that absolutely makes no sense... Could you try to log PRELUDE_POSITION before the if? Also you may change the if to be more explicit like |
Build issue was caused as I had a node.js file modified for testing which I reverted back. It seems the value evaluates to 0 strangely: Thu Jul 25 2024 11:25:37 GMT+0200 (GMT+02:00) - PAYLOAD_POSITION = 0 var PAYLOAD_POSITION = '42008064 ' | 0; |
@robertsLando I changed the code to
It evaluates to NaN. If I run the code inside a node.js normal environment it does what it should |
@robertsLando: I have the feeling the code is twice inside the final binary. In the exe I clearly can see
var PAYLOAD_POSITION = 0;
var PAYLOAD_POSITION_STRING = '42003456 '.trim();
log('PAYLOAD_POSITION_STRING = ' + PAYLOAD_POSITION_STRING);
if(PAYLOAD_POSITION_STRING.length != 0) {
PAYLOAD_POSITION = parseInt(PAYLOAD_POSITION_STRING);
}
var PAYLOAD_SIZE = 0;
var PAYLOAD_SIZE_STRING = '944 '.trim();
log('PAYLOAD_SIZE_STRING = ' + PAYLOAD_SIZE_STRING);
if(PAYLOAD_SIZE_STRING.length != 0) {
PAYLOAD_SIZE = parseInt(PAYLOAD_SIZE_STRING);
}
var PRELUDE_POSITION = 0;
var PRELUDE_POSITION_STRING = '42004400 '.trim();
log('PRELUDE_POSITION_STRING = ' + PRELUDE_POSITION_STRING);
if(PRELUDE_POSITION_STRING.length != 0) {
PRELUDE_POSITION = parseInt(PRELUDE_POSITION_STRING);
}
var PRELUDE_SIZE = 0;
var PRELUDE_SIZE_STRING = '74570 '.trim();
log('PRELUDE_SIZE_STRING = ' + PRELUDE_SIZE_STRING);
if(PRELUDE_SIZE_STRING.length != 0) {
PRELUDE_SIZE = parseInt(PRELUDE_SIZE_STRING);
}
log('PAYLOAD_POSITION = ' + PAYLOAD_POSITION);
log('PAYLOAD_SIZE = ' + PAYLOAD_SIZE);
log('PRELUDE_POSITION = ' + PRELUDE_POSITION);
log('PRELUDE_SIZE = ' + PRELUDE_SIZE);
but when I run the exe I get which is the original inside node\lib\internal\process\pre_execution.js So this also explains why the original code with the | 0 doesn't work because in the source code it is being replaced but not in the binary code. That is all what I can probably analyze as I have no idea what happens when bundeling it. Maybe somebody else can take over and have a look why the stuff is twice inside. |
@matthias-heller Those placeholders are replaced by pkg on build. See reference here: |
@robertsLando The function you are refering to is called. I put a trace also inside |
@matthias-heller could it be that for some reason the |
I don't think so. I opened the exe file in a binary editor. But when running this executable it is showing the non replaced string |
Did you opened the builded exe or the patched nodejs exe? |
@robertsLando: I opened the built exe file which I also started |
@matthias-heller the last thing to test IMO is to try building an exe with a previous nodejs version to see what you see inside it and compare. All this things are very strange |
@robertsLando: The stuff which I can compare inside the binary looks same. The byte code content looks totally different. I used the same version of pkg which is 5.12.0 I could see inside the final binary built with node.js 20.14.0 still entries which are the place holders. This is not happening with node.js 20.11.1 |
This is expected:
You could try to build it using |
Ok I think this is the most important thing now. Could you try to manually replace those entries values on the final binary with the same values you got in the working one? |
@robertsLando: I did, but changing a binary typically won't work, and this is the same situation here. So I tried and the executable crashes down. |
Did you make the changes without changing file size?
… Op do 25 jul 2024 om 15:28 schreef Matthias Heller ***@***.***
@robertsLando <https://github.com/robertsLando>: I could, but changing a
binary typically won't work, and this is the same situation here. So I
tried and the executable crashes down.
—
Reply to this email directly, view it on GitHub
<#37 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AZR2LMQFH2VQTBLJOEF6KADZOD4OVAVCNFSM6AAAAABJINNGUKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENJQGMZDGNZXGM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Yes I did. But this is inside the bytecode section I can't quarantee that the stuff before the string which is bytecode is still okay. But even without bytecode it crashes as then I will change the filesize anyway. So at least we know what the problem is. The four variables which should be filled while building the binary evaluate to 0 and it is not a matter of '// PRELUDE_SIZE //' | 0 but realle PRELUDE_SIZE and all the other variables are missing |
I confirm that also on linux build that PRELUDE_SIZE is not present, this means that for some reason the https://github.com/yao-pkg/pkg/blob/ba407efef1d2e611d4c192b93295dcaa023fea79/lib/producer.ts#L51 If so it meanst the inject should throw here: https://github.com/yao-pkg/pkg/blob/ba407efef1d2e611d4c192b93295dcaa023fea79/lib/producer.ts#L62 |
@robertsLando: Thank you for validating under linux. Are the other three place holders missing as well in linux? |
Yep |
Okay great at least we found the problem. So my roughly two days of investigating in my freetime was not waste. Now we have to solve it |
Yeah and thanks for that 🙏🏼 I wasted the same time making the other archs working 😆 Maintaining this repo is just a pain but unfortunately there is no real alternative right now as node SEA doesn't suite well for complex applications (yet). Anyway even if we discovered that I stll have no clue why that happens only on windows :( |
Yeah, but I thought under linux the place holders are also not filled, so maybe you can have a look why this happens and when it is somehow solved, I can try it under windows as well. If I could offer any help let me know. |
Just a stab in the dark here (and I am more then aware I could be looking like a twit/cowboy) LIne endings.... between *nix and windows, could that be messing with buffer lengths somehow, maybe in 20.14 they treated this differently ? given the difference in length between could it be |
Any news on this topic? |
@matthias-heller Unfortunately nope, I was thinking about merging this and do a new release then wait for people asking why windows isn't working to ask them help 😆 I know it's not cool but I'm running out of ideas and time is limited |
Seems that latest nodejs 18/20 builds were failing because of old GLIBC versions. I have upgraded both Dockerfile.linux and Dockerfile.linuxcross in order to use gcc 10, this allowed also to remove a workaround added on patches to disable
_SYS_RANDOM_H
andmsign-return-address=all
cflag