Node.bcrypt.js: symbol lookup error undefined symbol: _ZN4node19GetCurrentEventLoopEPN2v87IsolateE

[morgan92333]

I installed [email protected] version for my project. It worked for a while, but now when I start with node command, the program exit with this error:

node app.js
node: symbol lookup error: /var/www/myproject/node_modules/bcrypt/lib/binding/bcrypt_lib.node: undefined symbol: _ZN4node19GetCurrentEventLoopEPN2v87IsolateE

This is the case if I use with nodemon:

nodemon app.js
[nodemon] 1.15.0 [nodemon] to restart at any time, enterrs [nodemon] watching: *.* [nodemon] startingnode app.js /usr/local/bin/node: symbol lookup error: /var/www/myproject/node_modules/bcrypt/lib/binding/bcrypt_lib.node: undefined symbol: _ZN4node19GetCurrentEventLoopEPN2v87IsolateE [nodemon] failed to start process, "node" exec not found [nodemon] Error

If I use

nodejs app.js

Its works

My node version: v8.4.0
My nodejs version v8.11.3

[chandru89new]

+1 on this.

To replicate this:
Node version: 8.9.3 (LTS, stable)
Bcrypt version: 3.0.1

Run any file on node with a bcrypt function (like bcrypt.hash())

Getting this:
node: symbol lookup error: //node_modules/bcrypt/lib/binding/bcrypt_lib.node: undefined symbol: _ZN4node19GetCurrentEventLoopEPN2v87IsolateE

I was able to fix this by downgrading bcrypt to 2.0.0 (but that has a vulnerability so I cant use that on production).

Edit: Running Ubuntu 16.04 (Thanks @agathver)

[recrsn]

Please mention the OS

[jvt]

I'm also seeing this issue on macOS 10.14.

My terminal is outputting:

[1] dyld: lazy symbol binding failed: Symbol not found: __ZN4node19GetCurrentEventLoopEPN2v87IsolateE
[1]   Referenced from: /Users/jt/Documents/Projects/Brainy-Kidz/node_modules/bcrypt/lib/binding/bcrypt_lib.node
[1]   Expected in: flat namespace
[1]
[1] dyld: Symbol not found: __ZN4node19GetCurrentEventLoopEPN2v87IsolateE
[1]   Referenced from: /Users/jt/Documents/Projects/Brainy-Kidz/node_modules/bcrypt/lib/binding/bcrypt_lib.node
[1]   Expected in: flat namespace

[matthieu994]

Same error with Heroku, but not on local.

2018-10-01T03:59:18.027347+00:00 app[web.1]: node: symbol lookup error: /app/node_modules/bcrypt/lib/binding/bcrypt_lib.node: undefined symbol: _ZN4node19GetCurrentEventLoopEPN2v87IsolateE
2018-10-01T03:59:18.046547+00:00 app[web.1]: npm ERR! file sh
2018-10-01T03:59:18.046983+00:00 app[web.1]: npm ERR! code ELIFECYCLE
2018-10-01T03:59:18.047195+00:00 app[web.1]: npm ERR! errno ENOENT
2018-10-01T03:59:18.047395+00:00 app[web.1]: npm ERR! syscall spawn
2018-10-01T03:59:18.048720+00:00 app[web.1]: npm ERR! [email protected] start: `node server`
2018-10-01T03:59:18.048890+00:00 app[web.1]: npm ERR! spawn ENOENT
2018-10-01T03:59:18.049135+00:00 app[web.1]: npm ERR! 

[kirkins]

I'm also seeing this on Ubuntu 18.04

[kirkins]

Rolling back to 3.0.0 from 3.0.1 fixed it for me.

[yiliang114]

@kirkins thx npm i -D [email protected] is in effect

[rvpanoz]

same issue - rolling back to 3.0.0 as @kirkins said fixes the issue.

[recrsn]

It's unfortunate that the NodeJS folks broke API in between releases. There is nothing much we can do in this regard.
You can force a recompile using npm rebuild bcrypt --build-from-source

[zelongc]

Upgrading my Node engine from 8.9.0 to 8.12.0 solved the problem.

[thom-nic]

I'm concerned this issue is closed while the problem persists. It may be "NodeJS's fault" however the end result is an unusable build and a breaking change between 3.0.0 and 3.0.1 for certain users.

So, I understand it is w/r/t prebuilt bcrypt, which is built against a specific N-API and something in the API changed (somewhere between 8.9 and 8.12) without node revving the API version (v57.)

I can reproduce with bcrypt 3.0.2 and nodejs 8.9.4, on both MacOS and Linux.

I actually wonder if rolling back to v3.0.0 works for folks because there is no prebuilt package for v3.0.0-node-v57-darwin-x64-unknown (there are prebuilt darwin packages for bcrypt 3.0.1 and 3.0.2.) Or if v3.0.0 was just coincidentally built against an earlier version of node, before the breaking API change.

Adding npm rebuild bcrypt --build-from-source is problematic for folks who then need to update CI scripts to workaround this.

I could suggest, un-publishing the node-v57 prebuilt binaries - it would force the "build-from-source" fallback to always occur when no prebuilt binary is found.

[bpehlert]

I was having the same issue with my production build through Heroku. Updating my node and npm engines on my package.json file to be the latest versions fixed the problem. Running bcrypt 3.0.4.

[fortunee]

I was having the same issue with my production build through Heroku. Updating my node and npm engines on my package.json file to be the latest versions fixed the problem. Running bcrypt 3.0.4.

What versions did you bump them up to? @bpehlert

[bpehlert]

I just made sure that I had the newest versions of Node and NPM by
reinstalling them through the terminal. Here are the versions I have in my
package.json file:

"engines": {
"node": "10.15.3",
"npm": "6.4.1"
},

On Sat, Apr 6, 2019 at 12:33 PM Fortune Ekeruo [e-mail]
wrote:

I was having the same issue with my production build through Heroku.
Updating my node and npm engines on my package.json file to be the latest
versions fixed the problem. Running bcrypt 3.0.4.

What versions did you bump them up to? @bpehlert
https://github.com/bpehlert

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kelektiv/node.bcrypt.js/issues/656#issuecomment-480527112,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Aj25HlUCbQ79h4YUaItvM_FwPc3nISmnks5veOh4gaJpZM4W_GRM
.

[aslam7]

You can use bcryptjs

[KyrosDigital]

I think the docker container abernix/meteord:node-8.4.0-base may be using a version of node that causes this issue with bcrypt upon deployment.

I think when we are able to use a version of node that is 12.14.0 or above, we can then start using bcrypt 3.0.7, without the need to downgrade the package version to 3.0.0 when you want to deploy.

This would be ideal.

[NitroBAY]

I'm concerned this issue is closed while the problem persists. It may be "NodeJS's fault" however the end result is an unusable build and a breaking change between 3.0.0 and 3.0.1 for certain users.

So, I understand it is w/r/t prebuilt bcrypt, which is built against a specific N-API and something in the API changed (somewhere between 8.9 and 8.12) without node revving the API version (v57.)

I can reproduce with bcrypt 3.0.2 and nodejs 8.9.4, on both MacOS and Linux.

I actually wonder if rolling back to v3.0.0 works for folks because there is no prebuilt package for v3.0.0-node-v57-darwin-x64-unknown (there are prebuilt darwin packages for bcrypt 3.0.1 and 3.0.2.) Or if v3.0.0 was just coincidentally built against an earlier version of node, before the breaking API change.

Adding npm rebuild bcrypt --build-from-source is problematic for folks who then need to update CI scripts to workaround this.

I could suggest, un-publishing the node-v57 prebuilt binaries - it would force the "build-from-source" fallback to always occur when no prebuilt binary is found.

My production app has crashed because of this. This is especially sneaky that until one user signed in everything worked so I did not see that the app had a bug despite testing after deployment and during my sleep the entire app crashed causing very big troubles to my business.
So if the above suggestion is easy to apply on bcrypt's maintainers'end it would save a lot of unexpected crashing and at very very least update the table in the Readme.md to warn users that they should use bcrypt 3.0.0 with 8.9

[Imran-cse]

The issue still persists with node v10.16.3 and bcrypt v3.0.8

[kodie]

I think the docker container abernix/meteord:node-8.4.0-base may be using a version of node that causes this issue with bcrypt upon deployment.

I think when we are able to use a version of node that is 12.14.0 or above, we can then start using bcrypt 3.0.7, without the need to downgrade the package version to 3.0.0 when you want to deploy.

This would be ideal.

Upgrading my Node engine from 8.9.0 to 8.12.0 solved the problem.

We were using abernix/meteord:node-8.9.0-base in our Meteor.js project, changing that to abernix/meteord:node-8.12.0-base fixed our issue.