npm throws exception (node.js 10.16.0) #938
Comments
|
the same problem with nvm. Should I open separate bug for it? |
|
No, we can address both in this issue. |
|
Are there any updates on this? |
|
The same occurs when using nvm to manage versions of node. As a side-node, which almost looks related, using the arm64 builds of VS-code (https://github.com/headmelted/codebuilds/) also results in a similar load error. It seems like the relative load which was introduced in these later versions of Node isn't working right. Maybe there's a problem in now the working directory is calculated, or maybe there's an error with the loadpath? |
|
I've done some digging and this appears to be the same root cause as libuv/libuv#2282. NodeJS 10.16 added support for the statx system call (nodejs/node#26707). As of that time NodeJS has not been able to work correctly in UserLAnd. It seems like the proot wrapper, or the seccomp filter in UserLAnd is not correctly returning ENOSYS when trying to invoke the statx system call. |
|
Further digging seems to indicate that the cause is proot. The proot binary is swallowing the SIGSYS that seccomp is throwing from trying to invoke this system call. However, looking at the code in https://github.com/termux/proot I'm at a loss to explain that. It seems that if there is a SIGSYS then we should fall through to setting the return value to |
When extensions handle system calls they set the system call ID to 0 (PR_void). This is the same as what happens if a system call isn't understood by proot. On Android unknown system calls result in a SECCOMP failure (sending SIGSYS), rather than returning ENOSYS. This changes the behavour of SIGSYS handing to check if the call was handled by an extension. If the call was handled by an extention the call should return 0, since it has been handled outside that context. If it wasn't handled then we should return ENOSYS. This is because either that system call doesn't exist, or we aren't allowed to call it. Either way, since the point of proot is to adapt seccomp to other applications, we should return ENOSYS because as far as the system is concerned that system call doesn't exist. Major props to nhinds for writing a bunch of go programs to help narrow this down to the the SECCOMP filter and the handing of the SISSYS signal. This fixes headmelted/codebuilds#97 and CypherpunkArmory/UserLAnd#938
When extensions handle system calls they set the system call ID to 0 (PR_void). This is the same as what happens if a system call isn't understood by proot. On Android unknown system calls result in a SECCOMP failure (sending SIGSYS), rather than returning ENOSYS. This changes the behavour of SIGSYS handing to check if the call was handled by an extension. If the call was handled by an extention the call should return 0, since it has been handled outside that context. If it wasn't handled then we should return ENOSYS. This is because either that system call doesn't exist, or we aren't allowed to call it. Either way, since the point of proot is to adapt seccomp to other applications, we should return ENOSYS because as far as the system is concerned that system call doesn't exist. Major props to nhinds for writing a bunch of go programs to help narrow this down to the the SECCOMP filter and the handing of the SISSYS signal. This fixes headmelted/codebuilds#97 and CypherpunkArmory/UserLAnd#938
When extensions handle system calls they set the system call ID to 0 (PR_void). This is the same as what happens if a system call isn't understood by proot. On Android unknown system calls result in a SECCOMP failure (sending SIGSYS), rather than returning ENOSYS. This changes the behavour of SIGSYS handing to check if the call was handled by an extension. If the call was handled by an extention the call should return 0, since it has been handled outside that context. If it wasn't handled then we should return ENOSYS. This is because either that system call doesn't exist, or we aren't allowed to call it. Either way, since the point of proot is to adapt seccomp to other applications, we should return ENOSYS because as far as the system is concerned that system call doesn't exist. Major props to nhinds for writing a bunch of go programs to help narrow this down to the the SECCOMP filter and the handing of the SISSYS signal. This fixes headmelted/codebuilds#97 and CypherpunkArmory/UserLAnd#938
|
any solution to it yet ?? |
|
The issue in proot has been merged so I'm hopeful we'll get a new build once the author has time. They noted they could only work on this in their spare time so hopefully they have time soon. |
|
It is in version 2.7.1. |
|
I can confirm that i am able to install Node js using nvm. Thanks a lot :-) |
Describe the bug
in ssh terminal npm -v throws exception
internal/modules/cjs/loader.js:638
throw err;
^
Error: Cannot find module '../lib/utils/unsupported.js'
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:636:15)
at Function.Module._load (internal/modules/cjs/loader.js:562:25)
at Module.require (internal/modules/cjs/loader.js:690:17)
at require (internal/modules/cjs/helpers.js:25:18)
at /usr/bin/npm:19:21
at Object. (/usr/bin/npm:152:3)
at Module._compile (internal/modules/cjs/loader.js:776:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:787:10)
at Module.load (internal/modules/cjs/loader.js:653:32)
at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
Expected:
6.9.0
Steps to reproduce the behavior:
output:
v10.16.0
output:
internal/modules/cjs/loader.js:638
throw err;
^
Error: Cannot find module '../lib/utils/unsupported.js'
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:636:15)
at Function.Module._load (internal/modules/cjs/loader.js:562:25)
at Module.require (internal/modules/cjs/loader.js:690:17)
at require (internal/modules/cjs/helpers.js:25:18)
at /usr/bin/npm:19:21
at Object. (/usr/bin/npm:152:3)
at Module._compile (internal/modules/cjs/loader.js:776:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:787:10)
at Module.load (internal/modules/cjs/loader.js:653:32)
at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
Expected:
6.9.0
Screenshots
N/A
Device Information
Device: Galaxy S8
Android Version: P, 9
UserLAnd Version: 2.5.14-beta-335541
Whether the device is rooted: NO
Whether the device is running LineageOS: NO
The text was updated successfully, but these errors were encountered: