SIGSEGV after a random number of sharp calls on Electron + Artix Linux x64

[NyaomiDEV]

Are you using the latest version? Is the version currently in use as reported by npm ls sharp the same as the latest version as reported by npm view sharp dist-tags.latest?
Sharp v. 0.30.0.

What are the steps to reproduce?
Grab a WebP image (for example, a Youtube video thumbnail) and try to convert it to PNG again and again and again in a bunch of async/await method calls.

Thread 1 "electron" received signal SIGSEGV, Segmentation fault.
0x00007fffeda143d0 in ?? () from /home/naomi/Sorgenti/Sunamu/node_modules/sharp/build/Release/../.././vendor/8.12.2/linux-x64/lib/libvips-cpp.so.42

(so useful indeed! but I know it's libvips from here)

The kernel just writes it off as a general protection fault:

traps: electron[6550] general protection fault ip:7f85735073f5 sp:7ffd7e50f900 error:0 in libvips-cpp.so.42[7f8572a4f000+ae8000]

What is the expected behaviour?
Sharp handles all conversions without ever crashing, no matter how fast or how many concurrent calls there are.

Are you able to provide a minimal, standalone code sample, without other dependencies, that demonstrates this problem?
Run this under Electron! Vanilla Node.js doesn't have this bug.

const https = require("https");
const sharp = require("sharp");
function get(url){
	return new Promise(resolve => {
		https.get(url, (response) => {
			let _data = Buffer.alloc(0);
			response.on("data", (chunk) => _data = Buffer.concat([_data, chunk]));
			response.on("end", () => resolve(_data));
		});
	});
}
// setups out of the way here

const url = "https://i.ytimg.com/vi/ntUIv5pVC4Q/hqdefault.jpg?sqp=-oaymwEcCNACELwBSFXyq4qpAw4IARUAAIhCGAFwAcABBg==&rs=AOn4CLANZDELfwLQvLXJDP1uJd8_hcPUBg";

async function callMe(buf){
	console.log("original", buf);
	const sharpbuffer = await sharp(buf)
		.resize(512, 512, {withoutEnlargement: true})
		.png()
		.toBuffer();
	console.log("resized", sharpbuffer);
}

(async () => {
	const buf = await get(url);
	for(;;)
		await callMe(buf);
})();

Are you able to provide a sample image that helps explain the problem?
https://i.ytimg.com/vi/ntUIv5pVC4Q/hqdefault.jpg?sqp=-oaymwEcCNACELwBSFXyq4qpAw4IARUAAIhCGAFwAcABBg==&rs=AOn4CLANZDELfwLQvLXJDP1uJd8_hcPUBg

What is the output of running npx envinfo --binaries --system?

  System:
    OS: Linux 5.16 Artix Linux
    CPU: (16) x64 AMD Ryzen 7 3800XT 8-Core Processor
    Memory: 8.05 GB / 31.27 GB
    Container: Yes
    Shell: 5.8 - /usr/bin/zsh
  Binaries:
    Node: 16.13.1 - ~/.nvm/versions/node/v16.13.1/bin/node
    Yarn: 1.22.17 - /usr/bin/yarn
    npm: 8.1.2 - ~/.nvm/versions/node/v16.13.1/bin/npm

By the way, it says I run in a container, but I definitely am not. That's a bug in and of itself in envinfo I guess.

I am also using Electron v16.0.6
EDIT: Updated to 17.0.0 and this issue is still happening

[NyaomiDEV]

Using the second-latest version of this package without the precompiled libvips that you provide works around this issue; however, this is not really feasible for my use case, as I am trying to deploy an Electron application and I worry about users missing libvips in their systems.

On the other hand, downloading your second-latest precompiled libvips holds the same problem.

Since we're talking precompiled things, probably it's a good thing to mention that my system runs on GLibc version 2.33

[lovell]

Hi, thank you for the detailed report, I've been able to reproduce this on Ubuntu 20.04 using recent prebuilt electron binaries (v15 to v17) and prebuilt sharp/libvips binaries (v0.28.3 to v0.30.0).

As you say, this works as-expected when using Node.js itself, so there must be something different about electron that's causing or triggering this. I too can confirm there's no problem when using libvips as a globally-installed shared library.

In the past we've seen symbol clashes between the (many) shared libraries upon which electron on Linux depends and statically-linked libraries inside the prebuilt libvips-cpp.so file, but the latter no longer exposes any symbols it doesn't need to, and I'd expect it to crash almost instantly at start-up if this was still a problem.

ldd electron

$ ldd /tmp/node_modules/electron/dist/electron 
	linux-vdso.so.1 (0x00007fffdcdfe000)
	libffmpeg.so => /tmp/node_modules/electron/dist/libffmpeg.so (0x00007ff7d6c17000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff7d6bf8000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff7d6bd5000)
	libgmodule-2.0.so.0 => /lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007ff7d6bcf000)
	libgobject-2.0.so.0 => /lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007ff7d6b6f000)
	libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007ff7d6a46000)
	libxshmfence.so.1 => /lib/x86_64-linux-gnu/libxshmfence.so.1 (0x00007ff7d6842000)
	libgio-2.0.so.0 => /lib/x86_64-linux-gnu/libgio-2.0.so.0 (0x00007ff7d6661000)
	libnss3.so => /lib/x86_64-linux-gnu/libnss3.so (0x00007ff7d6512000)
	libnssutil3.so => /lib/x86_64-linux-gnu/libnssutil3.so (0x00007ff7d64df000)
	libsmime3.so => /lib/x86_64-linux-gnu/libsmime3.so (0x00007ff7d64af000)
	libnspr4.so => /lib/x86_64-linux-gnu/libnspr4.so (0x00007ff7d646f000)
	libatk-1.0.so.0 => /lib/x86_64-linux-gnu/libatk-1.0.so.0 (0x00007ff7d6443000)
	libatk-bridge-2.0.so.0 => /lib/x86_64-linux-gnu/libatk-bridge-2.0.so.0 (0x00007ff7d640c000)
	libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007ff7d63bb000)
	libdrm.so.2 => /lib/x86_64-linux-gnu/libdrm.so.2 (0x00007ff7d63a7000)
	libgtk-3.so.0 => /lib/x86_64-linux-gnu/libgtk-3.so.0 (0x00007ff7d5bf6000)
	libpango-1.0.so.0 => /lib/x86_64-linux-gnu/libpango-1.0.so.0 (0x00007ff7d5ba7000)
	libcairo.so.2 => /lib/x86_64-linux-gnu/libcairo.so.2 (0x00007ff7d5a82000)
	libgdk_pixbuf-2.0.so.0 => /lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 (0x00007ff7d5a5a000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff7d590b000)
	libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x00007ff7d57ce000)
	libXcomposite.so.1 => /lib/x86_64-linux-gnu/libXcomposite.so.1 (0x00007ff7d57c9000)
	libXdamage.so.1 => /lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007ff7d57c4000)
	libXext.so.6 => /lib/x86_64-linux-gnu/libXext.so.6 (0x00007ff7d57ad000)
	libXfixes.so.3 => /lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007ff7d57a5000)
	libXrandr.so.2 => /lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007ff7d5798000)
	libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007ff7d576a000)
	libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007ff7d5740000)
	libxkbcommon.so.0 => /lib/x86_64-linux-gnu/libxkbcommon.so.0 (0x00007ff7d56fe000)
	libgbm.so.1 => /lib/x86_64-linux-gnu/libgbm.so.1 (0x00007ff7d56eb000)
	libasound.so.2 => /lib/x86_64-linux-gnu/libasound.so.2 (0x00007ff7d55f0000)
	libatspi.so.0 => /lib/x86_64-linux-gnu/libatspi.so.0 (0x00007ff7d55b9000)
	libcups.so.2 => /lib/x86_64-linux-gnu/libcups.so.2 (0x00007ff7d551e000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff7d5503000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff7d5311000)
	/lib64/ld-linux-x86-64.so.2 (0x00007ff7dfc70000)
	libffi.so.7 => /lib/x86_64-linux-gnu/libffi.so.7 (0x00007ff7d5303000)
	libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007ff7d5290000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007ff7d5274000)
	libmount.so.1 => /lib/x86_64-linux-gnu/libmount.so.1 (0x00007ff7d5214000)
	libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007ff7d51e9000)
	libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007ff7d51cd000)
	libplc4.so => /lib/x86_64-linux-gnu/libplc4.so (0x00007ff7d51c4000)
	libplds4.so => /lib/x86_64-linux-gnu/libplds4.so (0x00007ff7d51bf000)
	libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007ff7d5110000)
	libgdk-3.so.0 => /lib/x86_64-linux-gnu/libgdk-3.so.0 (0x00007ff7d500b000)
	libpangocairo-1.0.so.0 => /lib/x86_64-linux-gnu/libpangocairo-1.0.so.0 (0x00007ff7d4ff9000)
	libXi.so.6 => /lib/x86_64-linux-gnu/libXi.so.6 (0x00007ff7d4fe5000)
	libcairo-gobject.so.2 => /lib/x86_64-linux-gnu/libcairo-gobject.so.2 (0x00007ff7d4fd9000)
	libepoxy.so.0 => /lib/x86_64-linux-gnu/libepoxy.so.0 (0x00007ff7d4ea6000)
	libfribidi.so.0 => /lib/x86_64-linux-gnu/libfribidi.so.0 (0x00007ff7d4e89000)
	libpangoft2-1.0.so.0 => /lib/x86_64-linux-gnu/libpangoft2-1.0.so.0 (0x00007ff7d4e70000)
	libharfbuzz.so.0 => /lib/x86_64-linux-gnu/libharfbuzz.so.0 (0x00007ff7d4d6b000)
	libfontconfig.so.1 => /lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007ff7d4d22000)
	libfreetype.so.6 => /lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007ff7d4c63000)
	libthai.so.0 => /lib/x86_64-linux-gnu/libthai.so.0 (0x00007ff7d4c58000)
	libpixman-1.so.0 => /lib/x86_64-linux-gnu/libpixman-1.so.0 (0x00007ff7d4bb1000)
	libpng16.so.16 => /lib/x86_64-linux-gnu/libpng16.so.16 (0x00007ff7d4b79000)
	libxcb-shm.so.0 => /lib/x86_64-linux-gnu/libxcb-shm.so.0 (0x00007ff7d4b72000)
	libxcb-render.so.0 => /lib/x86_64-linux-gnu/libxcb-render.so.0 (0x00007ff7d4b63000)
	libXrender.so.1 => /lib/x86_64-linux-gnu/libXrender.so.1 (0x00007ff7d4959000)
	libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007ff7d4953000)
	libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007ff7d494b000)
	libwayland-server.so.0 => /lib/x86_64-linux-gnu/libwayland-server.so.0 (0x00007ff7d4933000)
	libgssapi_krb5.so.2 => /lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007ff7d48e6000)
	libavahi-common.so.3 => /lib/x86_64-linux-gnu/libavahi-common.so.3 (0x00007ff7d48d8000)
	libavahi-client.so.3 => /lib/x86_64-linux-gnu/libavahi-client.so.3 (0x00007ff7d48c5000)
	libgnutls.so.30 => /lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007ff7d46ef000)
	libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x00007ff7d4696000)
	libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007ff7d4606000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007ff7d45fb000)
	liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007ff7d45d2000)
	liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x00007ff7d45b1000)
	libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007ff7d4493000)
	libXinerama.so.1 => /lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007ff7d448c000)
	libXcursor.so.1 => /lib/x86_64-linux-gnu/libXcursor.so.1 (0x00007ff7d447f000)
	libwayland-cursor.so.0 => /lib/x86_64-linux-gnu/libwayland-cursor.so.0 (0x00007ff7d4474000)
	libwayland-egl.so.1 => /lib/x86_64-linux-gnu/libwayland-egl.so.1 (0x00007ff7d446f000)
	libwayland-client.so.0 => /lib/x86_64-linux-gnu/libwayland-client.so.0 (0x00007ff7d445e000)
	libgraphite2.so.3 => /lib/x86_64-linux-gnu/libgraphite2.so.3 (0x00007ff7d442f000)
	libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007ff7d4426000)
	libdatrie.so.1 => /lib/x86_64-linux-gnu/libdatrie.so.1 (0x00007ff7d441c000)
	libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007ff7d4402000)
	libkrb5.so.3 => /lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007ff7d4325000)
	libk5crypto.so.3 => /lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007ff7d42f2000)
	libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007ff7d42eb000)
	libkrb5support.so.0 => /lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007ff7d42dc000)
	libp11-kit.so.0 => /lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007ff7d41a6000)
	libidn2.so.0 => /lib/x86_64-linux-gnu/libidn2.so.0 (0x00007ff7d4185000)
	libunistring.so.2 => /lib/x86_64-linux-gnu/libunistring.so.2 (0x00007ff7d4003000)
	libtasn1.so.6 => /lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007ff7d3feb000)
	libnettle.so.7 => /lib/x86_64-linux-gnu/libnettle.so.7 (0x00007ff7d3fb1000)
	libhogweed.so.5 => /lib/x86_64-linux-gnu/libhogweed.so.5 (0x00007ff7d3f7a000)
	libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 (0x00007ff7d3ef6000)
	libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007ff7d3ed3000)
	libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007ff7d3eca000)

The fact that electron can run quite happily for a minute or so before crashing seems more like a memory or garbage collection problem.

The next step is probably to create a debug build of the binary created by http://github.com/lovell/sharp-libvips so we can get a proper backtrace of the crash.

[NyaomiDEV]

The next step is probably to create a debug build of the binary created by http://github.com/lovell/sharp-libvips so we can get a proper backtrace of the crash.

Yeah, I've tried but I can't use docker myself. Been trying to compile it without docker in my host system with no success. I am at a loss, but if you manage to do that I will be super happy if you shared the lib with me so I can make my own testing as well.

Also, I've been force refreshing this page for hours now, does it show?

[kleisauke]

GDB backtrace with debugging symbols:

Thread 1 "electron" received signal SIGSEGV, Segmentation fault.
slab_allocator_alloc_chunk (chunk_size=chunk_size@entry=80) at ../glib/gslice.c:1380
1380	../glib/gslice.c: Directory not empty.
(gdb) bt
#0  slab_allocator_alloc_chunk (chunk_size=chunk_size@entry=80) at ../glib/gslice.c:1380
#1  0x00007fffdd44af40 in magazine_cache_pop_magazine (ix=4, countp=countp@entry=0x76000713058) at ../glib/gslice.c:770
#2  0x00007fffdd44afed in thread_memory_magazine1_reload (tmem=tmem@entry=0x76000713000, ix=ix@entry=4) at ../glib/gslice.c:845
#3  0x00007fffdd44bd70 in g_slice_alloc (mem_size=mem_size@entry=80) at ../glib/gslice.c:1061
#4  0x00007fffdd44bdf9 in g_slice_alloc0 (mem_size=80) at ../glib/gslice.c:1098
#5  0x00007fffdd539ccc in g_type_create_instance (type=<optimized out>) at ../gobject/gtype.c:1911
#6  0x00007fffdd520694 in g_object_new_internal (class=class@entry=0x760002be880, params=params@entry=0x0, n_params=n_params@entry=0) at ../gobject/gobject.c:2011
#7  0x00007fffdd522113 in g_object_new_with_propertiesPython Exception <class 'TypeError'>: can only concatenate str (not "NoneType") to str
 (object_type=, n_properties=0, names=names@entry=0x0, values=values@entry=0x0) at ../gobject/gobject.c:2181
#8  0x00007fffdd522aa7 in g_object_new (object_type=<optimized out>, first_property_name=<optimized out>) at ../gobject/gobject.c:1821
#9  0x00007fffdd36964b in vips_object_newPython Exception <class 'TypeError'>: can only concatenate str (not "NoneType") to str
 (type=type@entry=, set=set@entry=0x0, a=a@entry=0x0, b=b@entry=0x0) at ../libvips/iofuncs/object.c:2383
#10 0x00007fffdd34068f in vips_interpolate_new (nickname=<optimized out>) at ../libvips/resample/interpolate.c:638
#11 0x00007fffdd31ed28 in vips::VInterpolate::new_from_name(char const*, vips::VOption*) (name=<optimized out>, options=0x0) at ../cplusplus/VInterpolate.cpp:52
#12 0x00007fffde586699 in pipeline(Napi::CallbackInfo const&) () at /home/kleisauke/electron-test/node_modules/sharp/build/Release/sharp-linux-x64.node
#13 0x00007fffde594548 in Napi::details::CallbackData<Napi::Value (*)(Napi::CallbackInfo const&), Napi::Value>::Wrapper(napi_env__*, napi_callback_info__*) ()
    at /home/kleisauke/electron-test/node_modules/sharp/build/Release/sharp-linux-x64.node

PR #3083 seems to fix this for me. You can test this with:

SHARP_IGNORE_GLOBAL_LIBVIPS=1 \
  npm install lovell/sharp#main --build-from-source

Or with Yarn:

SHARP_IGNORE_GLOBAL_LIBVIPS=1 \
  yarn add lovell/sharp#main --build-from-source

[NyaomiDEV]

@kleisauke I use Yarn for my projects; any way to achieve the same effect with that?

[kleisauke]

I've updated my comment with installation info for Yarn.

[NyaomiDEV]

Sadly, Yarn doesn't expose commandline arguments to lifecycle scripts, so I need another way. I will follow this comment with a working Yarn command, for reference, if I am lucky to find it

[kleisauke]

I think you could use the npm_config_build_from_source=true environment variable for that. https://classic.yarnpkg.com/en/docs/envvars/#toc-npm-config

[NyaomiDEV]

I am leaving it running for a couple of minutes; if it doesn't crash, then nice work

[NyaomiDEV]

It works! Hope it makes into a release soon enough, so I can ship an update to my app in time

[lovell]

Thanks Kleis, amazing work. Do we know why electron exposed this? Different stack size?

[kleisauke]

I'm not quite sure why this was only a issue on Electron. It looks like a memory corruption issue, since I couldn't reproduce this when I set the G_SLICE=always-malloc environment variable.

[kleisauke]

FWIW, https://gitlab.gnome.org/GNOME/glib/-/issues/1079#note_991535 mentions a similar backtrace.

[kleisauke]

Here's is a simple reproducer without Electron:

G_SLICE=debug-blocks LD_PRELOAD=/lib64/libgobject-2.0.so.0 node test.js

GDB backtrace:

original <Buffer 52 49 46 46 b6 44 00 00 57 45 42 50 56 50 38 20 aa 44 00 00 d0 d2 00 9d 01 2a 50 01 bc 00 3e 51 20 8c 44 23 a2 21 17 9a 46 d0 38 05 04 b1 00 64 0f 7a ... 17548 more bytes>
GSlice: MemChecker: attempt to release non-allocated block: 0x4c00800 size=80

Thread 1 "node" received signal SIGABRT, Aborted.
__pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
44	      return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret) : 0;
(gdb) bt
#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1  0x00007ffff7aaf8f3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
#2  0x00007ffff7a626a6 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3  0x00007ffff7a4c7d3 in __GI_abort () at abort.c:79
#4  0x00007ffff7903d1d in g_slice_free1 (mem_size=<optimized out>, mem_block=<optimized out>, mem_block@entry=0x4c00800) at ../glib/gslice.c:1156
#5  0x00007ffff7f98ff5 in g_type_free_instance (instance=0x4c00800) at ../gobject/gtype.c:2008
#6  0x00007ffff5040643 in vips::VObject::operator=(vips::VObject const&) () at /home/kleisauke/electron-test/node_modules/sharp/build/Release/sharp-linux-x64.node
#7  0x00007ffff503de7f in pipeline(Napi::CallbackInfo const&) () at /home/kleisauke/electron-test/node_modules/sharp/build/Release/sharp-linux-x64.node
#8  0x00007ffff504a548 in Napi::details::CallbackData<Napi::Value (*)(Napi::CallbackInfo const&), Napi::Value>::Wrapper(napi_env__*, napi_callback_info__*) ()
    at /home/kleisauke/electron-test/node_modules/sharp/build/Release/sharp-linux-x64.node
#9  0x0000000000ab44dd in v8impl::(anonymous namespace)::FunctionCallbackWrapper::Invoke(v8::FunctionCallbackInfo<v8::Value> const&) ()
#10 0x0000000000d53cfe in v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<false>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::FunctionTemplateInfo>, v8::internal::Handle<v8::internal::Object>, v8::internal::BuiltinArguments) ()
#11 0x0000000000d5511f in v8::internal::Builtin_HandleApiCall(int, unsigned long*, v8::internal::Isolate*) ()
#12 0x00000000015f0b79 in Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_BuiltinExit ()
#13 0x000000000158354a in Builtins_InterpreterEntryTrampoline ()

[lovell]

v0.30.1 now available with the fix, thanks both.