npm Segmentation Fault

[dylhack]

Running commands like npm install causes a segmentation fault out of the box. This is how I installed the snap:

sudo snap install node --classic

This is the verbose logs:

[dylhack@840G6 test]$ npm i --verbose
npm info it worked if it ends with ok
npm verb cli [
npm verb cli   '/var/lib/snapd/snap/node/5485/bin/node',
npm verb cli   '/snap/node/5485/bin/npm',
npm verb cli   'i',
npm verb cli   '--verbose'
npm verb cli ]
npm info using [email protected]
npm info using [email protected]
npm verb npm-session d9dfc4fb0ab4e7cf
npm info lifecycle [email protected]~preinstall: [email protected]
npm timing stage:loadCurrentTree Completed in 10ms
npm timing stage:loadIdealTree:cloneCurrentTree Completed in 0ms
npm timing stage:loadIdealTree:loadShrinkwrap Completed in 1ms
npm timing stage:loadIdealTree:loadAllDepsIntoIdealTree Completed in 3ms
npm timing stage:loadIdealTree Completed in 7ms
npm timing stage:generateActionsToTake Completed in 5ms
npm verb correctMkdir /home/dylhack/.npm/_locks correctMkdir not in flight; initializing
npm verb lock using /home/dylhack/.npm/_locks/staging-00e589a355f4ba29.lock for /home/dylhack/test/node_modules/.staging
npm verb unlock done using /home/dylhack/.npm/_locks/staging-00e589a355f4ba29.lock for /home/dylhack/test/node_modules/.staging
npm timing stage:executeActions Completed in 22ms
npm timing stage:rollbackFailedOptional Completed in 12ms
npm info linkStuff [email protected]
npm info lifecycle [email protected]~install: [email protected]
Segmentation fault (core dumped)

Versions
NPM 6.14.15
NodeJS v14.18.1

[dylhack]

For the record npm works perfectly fine out of snap at this version.

[rvagg]

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).

[dylhack]

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.

[dylhack]

Oh and amd64 (x86_64 arch)

[rvagg]

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.

[rvagg]

sorry, I think that's --channel not --track

[dylhack]

I'll give it a try

[dylhack]

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.

[dylhack]

I do need 14 to work though because of a package that limits the engine to be v14.

[dylhack]

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)

[rvagg]

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.

[dylhack]

Ah that makes sense

[dylhack]

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

[dylhack]

The only reason I'm switching shells is because powershell doesn't mention the segmentation fault, it only outputs error code 139.

[rvagg]

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 🤷.

[dylhack]

That makes sense