Prebuilt: runtime error undefined symbol: _ZN2v87Isolate19CheckMemoryPressureEv after creating multiple canvases

[symil]

Issue

After creating a large number of canvases, the process crashes with the error message:

node: symbol lookup error: /path/to/project/node_modules/canvas/build/Release/canvas.node:
undefined symbol: _ZN2v87Isolate19CheckMemoryPressureEv

When testing with a standalone file that does nothing but creating canvases, it crashes after creating 100 canvases, but in my real application it crashes after creating the 3rd canvas. I'm guessing that it has to do with the total memory used by the process (as the error kind of indicate)s, which is much higher in my real application than in the standalone file.

I'm on Linux, and this error only happens when the cairo package is not installed. When it's installed everything works well.

Steps to Reproduce

var Canvas = require('canvas');
var list = [];
for (var i = 0; i < 100; i++) {
  var canvas = Canvas.createCanvas(200, 200);
  var ctx = canvas.getContext('2d');
  list.push({canvas, ctx});
}

Your Environment

• node-canvas v2.0.0-alpha-14
• Ubuntu 16.04
• package libcairo2 NOT installed

[zbjornson]

Odd, this same issue came up in opencv 11 days ago: justadudewhohacks/opencv4nodejs#408.

That's a v8 symbol, not cairo, so I don't know why that would matter. Did you rebuild node-canvas after installing libcairo2? If yes, the error going away would make more sense.

[symil]

Indeed the problem came from Node.js, upgrading to the latest version solved the issue! Cairo was not the problem, I must have done something more than installing/uninstalling it during my tests.

Thanks for the help!

[azangru]

@zbjornson I too had the same error: when I upgraded node-canvas from 2.0.0-alpha.7 to 2.0.1 and ran my test suite on Node v8.9.4, I was getting the error undefined symbol: _ZN2v87Isolate19CheckMemoryPressureEv coming from /node_modules/canvas/build/Release/canvas.node. The error went away after upgrading Node to the last LTS (v8.12.0), at least on my dev machine.

[zbjornson]

@azangru I think this was broken since Node.js v8.7.0 because of nodejs/node#15393, and fixed in v8.10.0 v8.12.0 (nodejs/node@1e316826ff).

[zbjornson]

Grr, GitHub ate my last comment.

I think this was a bug in Node.js that was introduced in nodejs/node@1e31682#diff-914a24037ebfe44cbfab4f4ca7ff117a and fixed in v8.12.0 by nodejs/node@d868eb7. Having a hard time figuring out what release the breaking commit was first found in.

[matonga]

Had the same problem, using nodejs from ubuntu/bionic repo (v8.10). After reading comment from @zbjornson decided to switch to nodejs.org repos (to upgrade to v8.12) and it worked. Should report this to Ubuntu maintainers... or wait until they decide to update upstream anyway.

[vishalpawar048]

I am already on node 8.12.0 still I have been facing symbol look up error.

[vishalpawar048]

My canvas version is 2.0.1 , node 8.12.0, node-gyp 3.8.0. Could anyone please help?

[matonga]

Hi @vishalpawar048 I have node 8.12.0 and canvas 2.0.1 too, working fine here. Don't know how to get my node-gyp version, though. What distro are you using? And how do I get my node-gyp version so we can compare?

[matonga]

Ok, that's very strange now, I have node-gyp version 3.8.0 too (got it with /usr/lib/node_modules/npm/bin/node-gyp-bin/node-gyp --version)

[gavinr]

@zbjornson you are saying that it's fixed at node v8.12.0. Since Lambda is at Node v8.10.0, does this mean this bug is preventing usage of this library in AWS Lambda until Lambda updates to Node v8.12?

[zbjornson]

@gavinr Yes, I think that is all correct. (That bug in Node.js would affect any library that uses that particular v8 API though.)

[johnf]

@zbjornson Do you think it's possible to work around this at all. Appreciate this isn't ca canvas bug, but this will make canvas unusable in lambda for quite a while I expect.

[zbjornson]

My guess is that it happens when we adjust the externally allocated memory tracking, but I'm not positive. If that's the case, it isn't strictly necessary, but I'm hesitant to remove it also as it aids the GC.

It's a bit kludgy, but you can spawn another version of Node from your Lambda function. I used to do this three years ago when Lambda only supported 0.10: https://github.com/zbjornson/lambda-deploy

Looks like someone just published an updated module that does the same thing:
https://hackernoon.com/so-i-still-cant-run-my-node-js-10-code-on-aws-lambda-or-can-i-d2a9e8b1eeec