Environment
- OS: Ubuntu 24.04.4 LTS (Kernel 6.17.0-20-generic)
- GLib: 2.80.0-6ubuntu3.8
- GObject: libgobject-2.0
- Node.js: v24.14.1
- sharp: 0.34.5 (bundled in Electron app,
@img/sharp-linux-x64)
- Electron: 41.2.0
- Runtime: Wayland (GNOME), AMD Cezanne APU
Description
We're experiencing random crashes in an Electron app that uses sharp for image processing. The crash occurs in a
libuv-worker thread when sharp::OpenInput() calls g_object_ref(), which triggers a GLib-GObject assertion
failure (G_IS_OBJECT (object)), resulting in SIGTRAP / Trace/breakpoint trap.
The crash is intermittent — sometimes the app starts fine, sometimes it crashes 2-3 times before succeeding. It
appears to be a race condition in multi-threaded usage.
Stack Trace (from gdb)
Thread 44 "libuv-worker" received signal SIGTRAP, Trace/breakpoint trap.
#0 0x00007ffff7eac671 in g_logv () at libglib-2.0.so.0
#1 0x00007ffff7eac923 in g_log () at libglib-2.0.so.0
#2 0x00007ffff79be9bc in g_object_ref () at libgobject-2.0.so.0
#3 0x00007fff5796d6e5 in sharp::OpenInput(sharp::InputDescriptor*) () at sharp-linux-x64.node
#4 0x00007fff5796f405 in ??? () at sharp-linux-x64.node
#5 0x00007fff57966eac in ??? () at sharp-linux-x64.node
#6 0x0000555558301537 in node::ThreadPoolWork::ScheduleWork()::{lambda(uv_work_s*)#1}::__invoke(uv_work_s*) ()
Workaround
Setting UV_THREADPOOL_SIZE=1 eliminates the crash completely, suggesting a thread-safety issue in libvips/GLib when
multiple worker threads call g_object_ref concurrently.
UV_THREADPOOL_SIZE=1 open-orpheus # No crash
UV_THREADPOOL_SIZE=4 open-orpheus # Random crash (default)
Additional Notes
- This issue was not reproducible in VMware Workstation with the same OS/software versions, but the same GLib
assertion failures were observed without the actual crash.
- Downgrading Electron from v41 to v40.8.5 reduced crash frequency but did not eliminate it.
- The issue seems specific to GLib 2.80 on Ubuntu 24.04.
Environment
@img/sharp-linux-x64)Description
We're experiencing random crashes in an Electron app that uses sharp for image processing. The crash occurs in a
libuv-workerthread whensharp::OpenInput()callsg_object_ref(), which triggers a GLib-GObject assertionfailure (
G_IS_OBJECT (object)), resulting inSIGTRAP / Trace/breakpoint trap.The crash is intermittent — sometimes the app starts fine, sometimes it crashes 2-3 times before succeeding. It
appears to be a race condition in multi-threaded usage.
Stack Trace (from gdb)
Thread 44 "libuv-worker" received signal SIGTRAP, Trace/breakpoint trap.
#0 0x00007ffff7eac671 in g_logv () at libglib-2.0.so.0
#1 0x00007ffff7eac923 in g_log () at libglib-2.0.so.0
#2 0x00007ffff79be9bc in g_object_ref () at libgobject-2.0.so.0
#3 0x00007fff5796d6e5 in sharp::OpenInput(sharp::InputDescriptor*) () at sharp-linux-x64.node
#4 0x00007fff5796f405 in ??? () at sharp-linux-x64.node
#5 0x00007fff57966eac in ??? () at sharp-linux-x64.node
#6 0x0000555558301537 in node::ThreadPoolWork::ScheduleWork()::{lambda(uv_work_s*)#1}::__invoke(uv_work_s*) ()
Workaround
Setting
UV_THREADPOOL_SIZE=1eliminates the crash completely, suggesting a thread-safety issue in libvips/GLib whenmultiple worker threads call
g_object_refconcurrently.