Skip to content
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

undefined symbol: crypto_core_ed25519_scalarbytes #93

Closed
jfr3000 opened this issue Feb 18, 2019 · 19 comments
Closed

undefined symbol: crypto_core_ed25519_scalarbytes #93

jfr3000 opened this issue Feb 18, 2019 · 19 comments

Comments

@jfr3000
Copy link

jfr3000 commented Feb 18, 2019

This happens using the linux-x64/node-67.node prebuild. 2.2.6 works for me, so I guess this was introduced very recently? Any suggestions?

@emilbayes
Copy link
Member

Hmm, this is strange. Our canary setup has not reported any errors and we cannot reproduce: https://travis-ci.org/sodium-friends/sodium-native-citgm/jobs/494464274

Are we correct in assuming you're using latest Node (11.x)? That's what I guessed from node-67 (ABI 67)

@mafintosh
Copy link
Member

Also can you share the output of ldd node-67.node ?

@jfr3000
Copy link
Author

jfr3000 commented Feb 18, 2019

Yes, I'm using 11.9 but I tried different node versions, and the result was the same :(

ldd ./node_modules/sodium-native/prebuilds/linux-x64/node-67.node
	linux-vdso.so.1 =>  (0x00007ffc8adf7000)
	libsodium.so.23 => ./node_modules/sodium-native/prebuilds/linux-x64/libsodium.so.23 (0x00007f47c9075000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f47c8cf3000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f47c8ad6000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f47c870c000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f47c9502000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f47c8403000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f47c81ed000)

@emilbayes
Copy link
Member

@jfr3000 It all seems normal to me. You can try going to the sodium-native directory in our node_modules and run npm install from there. That should recompile in your case, but I just want to see what happens.

@jfr3000
Copy link
Author

jfr3000 commented Mar 2, 2019

Did that, and same result 🤷‍♀️ @regular is having the same issue on his machine. Guess I'll stick with the workaround for now...

@christianbundy
Copy link
Contributor

I can also reproduce this with Electron 2 (ABI 57, same as Node 8.0.0). Here's what I'm seeing:

/home/christianbundy/src/ssbc/patchwork/node_modules/electron/dist/electron --type=renderer --no-sandbox --service-pipe-token=CC461C4E397CF030BCCB2A569F3C27AD --lang=en-US --app-path=/home/christianbundy/src/ssbc/patchwork/node_modules/electron/dist/resources/default_app.asar --node-integration=true --webview-tag=true --no-sandbox --background-color=#fff --context-id=2 --enable-pinch --num-raster-threads=2 --enable-main-frame-before-activation --content-image-texture-target=0,0,3553;0,1,3553;0,2,3553;0,3,3553;0,4,3553;0,5,3553;0,6,3553;0,7,3553;0,8,3553;0,9,3553;0,10,3553;0,11,3553;0,12,3553;0,13,3553;0,14,3553;0,15,3553;0,16,3553;0,17,3553;1,0,3553;1,1,3553;1,2,3553;1,3,3553;1,4,3553;1,5,3553;1,6,3553;1,7,3553;1,8,3553;1,9,3553;1,10,3553;1,11,3553;1,12,3553;1,13,3553;1,14,3553;1,15,3553;1,16,3553;1,17,3553;2,0,3553;2,1,3553;2,2,3553;2,3,3553;2,4,3553;2,5,3553;2,6,3553;2,7,3553;2,8,3553;2,9,3553;2,10,3553;2,11,3553;2,12,3553;2,13,3553;2,14,3553;2,15,3553;2,16,3553;2,17,3553;3,0,3553;3,1,3553;3,2,3553;3,3,3553;3,4,3553;3,5,3553;3,6,3553;3,7,3553;3,8,3553;3,9,3553;3,10,3553;3,11,3553;3,12,3553;3,13,3553;3,14,3553;3,15,3553;3,16,3553;3,17,3553;4,0,3553;4,1,3553;4,2,3553;4,3,3553;4,4,3553;4,5,3553;4,6,3553;4,7,3553;4,8,3553;4,9,3553;4,10,3553;4,11,3553;4,12,3553;4,13,3553;4,14,3553;4,15,3553;4,16,3553;4,17,3553 --disable-accelerated-video-decode --enable-gpu-async-worker-context --service-request-channel-token=CC461C4E397CF030BCCB2A569F3C27AD --renderer-client-id=4 --shared-files=v8_natives_data:100,v8_snapshot_data:101: symbol lookup error: /home/christianbundy/src/ssbc/patchwork/node_modules/ssb-server/node_modules/sodium-native/prebuilds/linux-x64/electron-57.node: undefined symbol: crypto_core_ed25519_scalarbytes

@emilbayes
Copy link
Member

@christianbundy can you please run lld like above and report back? Also OS details would be helpful. We have a canary that test every night and have done extensive manual testing (we’re working on an electron app on macOS and Linux) and have not had these issues, so we suspect that something is wrong with your dynamic linker perhaps

@christianbundy
Copy link
Contributor

Sorry for the noise, I've tried reinstalling with npm install and now it seems to work. I'm not sure what was going on but it's gone now. Maybe my machine is haunted?

@regular
Copy link

regular commented Mar 28, 2019

@christianbundy you machine is probably alright. I am having this problem since a month or so, on both Linux and OSX. It happens so often that I've learned to live with it and my zsh autocompletes npm i s to npm i sodium-native@2.2.6

@mafintosh
Copy link
Member

@regular we have a hard time reproducing, does this happen to you regularly with 2.3.0?

@emilbayes
Copy link
Member

@regular Can you please provide details of your OS and the ldd output so we can debug further?

@emilbayes
Copy link
Member

@regular @jfr3000 Are you running sodium-native through electron? Just fell over this: electron-userland/electron-builder#3590

@emilbayes
Copy link
Member

I know what is going on now thanks to @andrewosh. Two different versions of libsodium are trying to be loaded, both compatible but one has a few more features than the other. It is something I've been working on for a while but never saw having practical relevance. Will try to come up with a fix for the new release

@mixmix
Copy link
Contributor

mixmix commented May 16, 2019

Oh look, a scuttlebutt party.

I'm hitting this bug with electron-builder (this branch of patchbay). What I'm seeing is that npm start works, but when I try to build a release I get this error.
Messed with build config (made it more wasteful, less fancy) and now I'm not getting misaligned libsodium

@emilbayes
Copy link
Member

emilbayes commented May 16, 2019

@mixmix electron-builders rebuild logic seems broken :( We've had to introduce a flag to disable the prebuilding logic for node-gyp-build: prebuild/node-gyp-build@05d27cb

The above fix I thought I'd found, I couldn't get to reproduce. I have the test case here: https://github.com/emilbayes/sodium-symbol-bug. Maybe someone could provide a complete tree of what the final electron app looks like (including the asar bundle) so I can see if competing versions of sodium-native is actually the cause. A package-lock.json file from a bugged build may also work

@vweevers
Copy link

vweevers commented Oct 23, 2019

Here's a repro that works on (at least) ubuntu and windows: https://github.com/vweevers/sodium-symbol-bug/tree/npm-aliases.

What may help (probably not for this specific issue but you should do it anyway for mac), is adding the following to binding.gyp:

["OS == 'mac'", {
   "cflags+": ["-fvisibility=hidden"],
   "xcode_settings": {
     "GCC_SYMBOLS_PRIVATE_EXTERN": "YES" # -fvisibility=hidden
   }
}]

To make symbols hidden. Because the problem is, on mac, dlopen() defaults to RTLD_GLOBAL, which means if the node addon has any global symbols, they will be exported, causing conflicts if you then load another addon that has symbols with the same names.

See also nodejs/node-gyp#1891 and https://github.com/vweevers/about-native-modules

@vweevers
Copy link

vweevers commented Nov 3, 2019

Update: doesn't happen on mac, only ubuntu and windows. And only when using prebuilt binaries. Here's an alternative way to reproduce, that runs the tests of sodium-native. Its output shows which versions can't be loaded into the same process:

2.4.6 2.4.2 2.3.0 2.2.6 2.2.5
2.4.6 - OK OK ERR ERR
2.4.2 OK - OK ERR ERR
2.3.0 OK OK - ERR ERR
2.2.6 OK OK OK - OK
2.2.5 OK OK OK OK -

@mafintosh
Copy link
Member

I think this is fixed, if not reopen

@tacerus
Copy link

tacerus commented Aug 28, 2022

Hi! Could you link the commit or PR fixing this? I only notice #1046 mentioned, but that one was closed with no merge.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants