Segmentation Fault on Node alpine #528
Labels
Comments
|
Try adding a |
|
Yep, that works: Click to expandIs this my problem then? Or should the |
Yes, node-pre-gyp should be building this binary from source, by detecting ABI incompatibility of pre-built binary. Earlier we did not have Linux binaries at all, so no one faced this issue. I had filed a bug mapbox/node-pre-gyp#265 I have added a note to the installation instructions wiki here: |
This was referenced Jul 9, 2017
|
Is there an earlier version I can use for which there are no prebuilt binaries, so I don't have to rebuild the module? |
|
@marcbachmann You can use There are no bug-free versions without pre-built binaries. |
|
Rebuilding isn't a simple workaround when you use bcrypyt in a module which is a dependency of other modules. They would have to do the same. I'll have to check wether |
|
Hmm The code |
|
Did you install the dependencies for bcrypt source compiling inside Docker ?
|
|
Yeah, It's something about the latest version of bcrypt, apline, and docker that is causing it to seg fault. It started happening around 4 to 6 days ago as well. |
|
Could you attach the output of docker build ? Also mention your base image.
This is quite strange. I cannot reproduce your problem in the latest version of nodejs:6-alpine or nodejs:8-alpine
|
|
Same here, the image I use This is the only log output related to bcrypt Fortunately running |
|
Looks like there are two kind of errors. I haven't experienced the segfault. $ docker run -it --rm mhart/alpine-node:6 /bin/sh -c 'npm install bcrypt && node -e "require(\"bcrypt\")"'
[bcrypt] Success: "/node_modules/bcrypt/lib/binding/bcrypt_lib.node" is installed via remote
/
`-- bcrypt@1.0.2
+-- bindings@1.2.1
+-- nan@2.5.0
`-- node-pre-gyp@0.6.32
+-- mkdirp@0.5.1
| `-- minimist@0.0.8
+-- nopt@3.0.6
| `-- abbrev@1.1.0
+-- npmlog@4.1.2
| +-- are-we-there-yet@1.1.4
.... list of modules
module.js:597
return process.dlopen(module, path._makeLong(filename));
^
Error: Error relocating /node_modules/bcrypt/lib/binding/bcrypt_lib.node: __snprintf_chk: symbol not found
at Error (native)
at Object.Module._extensions..node (module.js:597:18)
at Module.load (module.js:487:32)
at tryModuleLoad (module.js:446:12)
at Function.Module._load (module.js:438:3)
at Module.require (module.js:497:17)
at require (internal/module.js:20:19)
at Object.<anonymous> (/node_modules/bcrypt/bcrypt.js:6:16)
at Module._compile (module.js:570:32)
at Object.Module._extensions..js (module.js:579:10) |
|
@marcbachmann @teckays We are aware of the segfault issue. We have #530 to track this. Currently this issue is due to mapbox/node-pre-gyp#309 @marcbachmann As per node-pre-gyp docs, using |
2 tasks
|
hi, I have a similar issue here, but I use Dockerfile to sudo docker run c1
npm info it worked if it ends with ok
npm info using npm@5.3.0
npm info using node@v8.4.0
> node app.js
module.js:602
return process.dlopen(module, path._makeLong(filename));
^
Error: The module '/usr/src/app/node_modules/bcrypt/lib/binding/bcrypt_lib.node'
was compiled against a different Node.js version using
NODE_MODULE_VERSION 51. This version of Node.js requires
NODE_MODULE_VERSION 57. Please try re-compiling or re-installing
the module (for instance, using `npm rebuild` or `npm install`).
...the # Use an official Python runtime as parent image
FROM node:8.4
# Set the working directory to /usr/src/app
RUN mkdir -p /usr/src/app
WORKDIR /usr/src/app
# Copy the current directory contents into the container at /usr/src/app
COPY back-end-sourse/ /usr/src/app
# Make port 9090 available to the world
EXPOSE 9090
# Run "npm start" when then container launches
CMD ["npm", "start"]After I found here, I also tried But there is the same issue coming. |
|
@XidongHuang
Are you including the node_modules folder from your host ? You may need to add a |
|
@agathver thinks for your quick reply! Then can run it as expected. |
|
First - I'm fairly new so please forgive if I am making a rookie error. I tried Any direction is greatly appreciated! |
|
@scooterbee Your error is unrelated to this one. It's due to unavailablitly of compilers on your system and compiled modules on our part. #540 is tracking this. I have triggered a build so installing bcrypt on windows should work fine in ~30 mins. |
|
@agathver Thank you so much! |
|
I also had this issue, here is my |
|
For all those you didn't get it to work after adding cc @idmontie |
romancin
added a commit
to romancin/rutorrent-flood-docker
that referenced
this issue
Nov 3, 2017
Problem discussed here: kelektiv/node.bcrypt.js#528 It seems a problem with bcrypt, nodejs v8 and alpine.
This was referenced Nov 3, 2017
|
I'm running a node.js app inside docker, here are the relevant parts of my dockerfile: What am I missing? |
|
@arivatibm There are so many points of failure in this such as symlinking gcrypt into crypt. You are getting error in requiring However, are you getting a segfault on |
monsonjeremy
referenced
this issue
in monsonjeremy/Surfline-Project
Jan 3, 2018
|
Looks like mapbox/node-pre-gyp#309 has been closed. Can we make progress on this now? |
|
in the meantime, https://github.com/dcodeIO/bcrypt.js has the same interface |
|
@jwalton PRs welcome. It will take me a while to write code for that, given my state now. |
|
Kind of fix could possibly be the following addition in your Dockerfiles. |
|
People replacing native bcrypt with JS bcrypt seems really bad... The whole point of bcrypt is to "do a hard thing" a number of times such that it's much harder for an attacker to replicate. If you make it intentionally slower (by probably a great deal) you materially hurt the security. Right? |
|
@djMax - I'm not 100% sure what that has to do with this PR, but I don't think you are correct. The bcrypt algorithm is no different whether it's written JS or C++ or brainfuck. Using the same number of rounds will yield the same security, regardless of the language, as long as the random number sources are of equivalent quality. |
|
Sure, if they use the same rounds that's a fair point. Though those rounds will be significantly slower and thus encourage them to reduce the rounds or not raise them with "the times." Of all the things to do native, though, this is high up on the list. |
|
Ah yes, I see what you mean. I do agree that this is a great use case for a native driver, but I also think there are good reasons why a pure-JS implementation could be desirable. It's not obvious to me that it would be that much slower, and it would alleviate an entire class of issues. For most programs, bcrypt is only used during authentication; adding an extra half-second to that step probably won't even be noticeable. Anyhow, the entire category of js-vs-native tradeoffs is about to become a non-issue with WebASM making great progress :) |
|
Since this bug is closed, does it mean that the wiki section for Installation-Instructions for Alpine is slightly outdated and there is no need to run |
5 tasks
|
The docs mention
I'm using version 5 But I'm still seeing this issue, do I need to install python and compile bcrypt myself even though I'm on a major version beyond the one which experimentally introduced the bindings for alpine? |
|
If you are still seeing this issue, just double check if you are including glibc binaries from the host by any chance. It's no longer experimental. |
|
How do I check if I'm including those libraries @recrsn? Here's my full Dockerfile and .dockerignore: If I alter my dockerfile to not run and the output when building of just the Is there something else I should check for to verify when the glibc libraries are being included? Do I need to use a more modern version of node? |
fast-facts
pushed a commit
to fast-facts/node.bcrypt.js
that referenced
this issue
Jun 17, 2022
Only glibc supported as of now. Closes kelektiv#559, kelektiv#530, kelektiv#528
|
if anyone using node:16-alpine docker use this command: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Forgive me if I've missed something obvious, but I have a reproducible segmentation fault using the latest Docker alpine image for Node:
Output:
Click to expand
Seems to affect older Alpine versions too. It seems possible it's related to nodejs/node#14069. The default Node image using
buildpack-depsdoesn't exhibit the problem.The text was updated successfully, but these errors were encountered: