Open dylhack opened 2 years ago
For the record npm works perfectly fine out of snap at this version.
ooof, that's not healthy Can you provide more details about operating system, version, architecture and also if there's anything that might be interesting in the list of things to install in this package? i.e. are there addons to compile? Does this happen with a completely clean node_modules (i.e. delete it and try again)? There may be an addon getting in the way here, although it's strange to have one being loaded during install (though not impossible).
Kernel: Linux 5.10.74-1-LTS Distro: Endeavor (Arch base) Snap 2.53-1 snapd 2.53-1 series 16
list of things to install in this package:
The funny thing is, there isn't anything it is installing. Simply running npm i
will cause the segmentation fault and same goes for practical use. I tried clearing NPM's cache and removed all the node modules globally.
Oh and amd64 (x86_64 arch)
sudo snap refresh node --track 16
and see if node 16 has the same problem, it's got a different base distro (iirc 14 is on ubuntu 16 and 16 is on 18). That isn't supposed to be a problem, snaps have their own isolated environment so aren't supposed to rely on system libraries or anything special outside of its little snap space.
sorry, I think that's --channel
not --track
I'll give it a try
PS /home/dylhack> sudo snap refresh node --channel 16
node (16/stable) 16.12.0 from OpenJS Foundation (iojs✓) refreshed
PS /home/dylhack> whereis npm
npm: /var/lib/snapd/snap/bin/npm
PS /home/dylhack/test> npm i through2
added 6 packages, and audited 7 packages in 1s
Yeah works fine on 16.
I do need 14 to work though because of a package that limits the engine to be v14.
Does ldd absolutely know if npm is relying on libraries in these exact paths? I can't believe that, but if it's true it looks like it's relying on libc outside of the snap environment.
PS /home/dylhack/test> ldd /var/lib/snapd/snap/bin/npm
linux-vdso.so.1 (0x00007fff0fbbf000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f49b6c3a000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f49b6a6e000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f49b7d67000)
It's supposed to be relying on libraries in its own isolated environment, that's intended to be part of the magic of snaps. What you're looking at is not the libraries for npm
, the binary you're inspecting is just the snap
binary (ls -l
and you should see it's a symlink) that sets up the environment for the snap in question and defers into that snap for the command its been called with.
Ah that makes sense
PS /home/dylhack/test> sudo snap refresh node --channel 14
node (14/stable) 14.18.1 from OpenJS Foundation (iojs✓) refreshed
PS /home/dylhack/test> bash
[dylhack@840G6 test]$ npm i through2
Segmentation fault (core dumped)ailedOptional: verb npm-session 2f9ccfa3664614b
[dylhack@840G6 test]$
Here's 14
The only reason I'm switching shells is because powershell doesn't mention the segmentation fault, it only outputs error code 139.
Sorry, I'm not at all sure what's going on here. Maybe this is something best taken up with the Snap folks @ https://forum.snapcraft.io/? It sounds like an odd interaction with the distro you're using. Maybe Snap isn't setting up its environment properly. I suspect an important bit of information is the base, I think that our Node 14 snap is defaulting to "core16" (https://github.com/nodejs/snap/blob/node14/snapcraft.yaml) while 16 and above are explicitly set to "core20" (https://github.com/nodejs/snap/blob/node16/snapcraft.yaml - not the 18 that I suggested above). But even there, if there was something wrong with the linking isolation then I'd have thought the older one, compiled and linking against older libraries, should be safer with the newer distro version. I'm at a loss, sorry 🤷.
That makes sense
Running commands like
npm install
causes a segmentation fault out of the box. This is how I installed the snap:This is the verbose logs:
Versions NPM 6.14.15 NodeJS v14.18.1