Closed mtorp closed 4 years ago
Hi Martin,
that's strange and I can't reproduce it. Which GraalVM version is that node
from? Is it a custom build? There's a release
file in the parent dir of the bin
folder with exact versions.
I can also put a workaround into jalangi.js
, but I'd like to know what the cause is too.
Here's the output of the release file.
I use the node in workspace-nodeprof/graal/sdk/latest_graalvm_home
following the install structure you suggest in the README.
JAVA_VERSION="1.8.0_172"
OS_NAME="Linux"
OS_VERSION="2.6"
OS_ARCH="amd64"
SOURCE=" jvmci:62cf614220f2 graal-js:d5fab58657aeae150740ee370eee6fd4ed60b5b8 graal-nodejs:d5fab58657aeae150740ee370eee6fd4ed60b5b8 nodeprof:e464d39d4f731ed8b01ed69b79ae4a78d0a7d1a5 regex:f7b99744efd1899ff951543ab5a0061964c6c81d sdk:f7b99744efd1899ff951543ab5a0061964c6c81d truffle:f7b99744efd1899ff951543ab5a0061964c6c81d"
GRAALVM_VERSION="20.1.0-dev"
COMMIT_INFO={"graal-js": {"commit.committer": "Alexander Jordan <alexander.jordan@oracle.com>", "commit.committer-ts": 1585274790, "commit.rev": "d5fab58657aeae150740ee370eee6fd4ed60b5b8"}, "graal-nodejs": {"commit.committer": "Alexander Jordan <alexander.jordan@oracle.com>", "commit.committer-ts": 1585274790, "commit.rev": "d5fab58657aeae150740ee370eee6fd4ed60b5b8"}, "nodeprof": {"commit.committer": "Alexander Jordan <alexander.jordan@oracle.com>", "commit.committer-ts": 1585557250, "commit.rev": "e464d39d4f731ed8b01ed69b79ae4a78d0a7d1a5"}, "regex": {"commit.committer": "Tom\u00e1\u0161 Zezula <tomas.zezula@oracle.com>", "commit.committer-ts": 1584355812, "commit.rev": "f7b99744efd1899ff951543ab5a0061964c6c81d"}, "sdk": {"commit.committer": "Tom\u00e1\u0161 Zezula <tomas.zezula@oracle.com>", "commit.committer-ts": 1584355812, "commit.rev": "f7b99744efd1899ff951543ab5a0061964c6c81d"}, "truffle": {"commit.committer": "Tom\u00e1\u0161 Zezula <tomas.zezula@oracle.com>", "commit.committer-ts": 1584355812, "commit.rev": "f7b99744efd1899ff951543ab5a0061964c6c81d"}}
I have the same versions, so I'm assuming it's a side effect of something happening during initialization of your analysis. You could try with one of the test analyses instead, I was using test/npm-analysis.js
.
Anyway, #72 is going to avoid the Promise creation during startup when it's not necessary, which should make it more robust.
I have found the problem now. You are right that it was an issue in our analysis initialization. It contains an async init hook that expects the first call of the hook to have the type parameter set to 'TCPWRAP', which is not the case if the initialization is wrapped in a promise. Anyway thanks for the help and sorry to bother you with this issue.
The startupPromises feature in jalangi.js seems to have broken my analysis.
When starting the analysis the following error is printed and the program to be analyzed isn't started.
Error: async of type PROMISE created with suspiciously small call stack
It works without any issues, when I replace
with
in jalangi.js.
I use the following command to start the NodeProf analysis:
node --jvm --experimental-options --vm.Dtruffle.class.path.append=nodeprof.jar --nodeprof.Scope=all --nodeprof jalangi.js --analysis /path/to/analysis.js app.js