sharp: Use of process.exit in mocha timeout causes GLib-CRITICAL on noflo-sharp

First of all, I couldn’t reproduce this on sharp alone, even using the same code snippet. However I can’t help finding a solution for it, and since it’s related with sharp, I’m hoping we can investigate it together 😄.

While trying to send this GIF file to Resize component on noflo-sharp (I have a test for this case), I’m getting the following:

(sharp:5885): GLib-CRITICAL **: g_hash_table_lookup: assertion 'hash_table != NULL' failed
Trace/breakpoint trap (core dumped)

I’m being able to reproduce it on an Ubuntu 14.04 box using latest sharp, and the same happens on Travis CI.

While analyzing the core dump executing by gdb --args $(which node) ./node_modules/.bin/mocha spec/Resize (on noflo-sharp):

GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/vilson/.nvm/versions/node/v4.2.6/bin/node...done.
(gdb) core core
warning: core file may not match specified executable file.
[New LWP 28674]
[New LWP 28667]
[New LWP 28668]
[New LWP 28664]
[New LWP 28665]
[New LWP 28666]
Traceback (most recent call last):
  File "/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19-gdb.py", line 63, in <module>
    from libstdcxx.v6.printers import register_libstdcxx_printers
ImportError: No module named 'libstdcxx'
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `grunt                                          '.
Program terminated with signal SIGTRAP, Trace/breakpoint trap.
#0  0x00007f7194078d0c in g_logv ()
   from /home/vilson/src/noflo/noflo-sharp/node_modules/sharp/build/Release/../../lib/libglib-2.0.so.0
(gdb) bt full
#0  0x00007f7194078d0c in g_logv ()
   from /home/vilson/src/noflo/noflo-sharp/node_modules/sharp/build/Release/../../lib/libglib-2.0.so.0
No symbol table info available.
#1  0x00007f7194078e92 in g_log ()
   from /home/vilson/src/noflo/noflo-sharp/node_modules/sharp/build/Release/../../lib/libglib-2.0.so.0
No symbol table info available.
#2  0x00007f719405d9f4 in g_hash_table_lookup ()
   from /home/vilson/src/noflo/noflo-sharp/node_modules/sharp/build/Release/../../lib/libglib-2.0.so.0
No symbol table info available.
#3  0x00007f7187b98824 in vips_cache_operation_lookup ()
   from /home/vilson/src/noflo/noflo-sharp/node_modules/sharp/build/Release/../../lib/libvips.so.42
No symbol table info available.
#4  0x00007f7187b98a59 in vips_cache_operation_buildp ()
   from /home/vilson/src/noflo/noflo-sharp/node_modules/sharp/build/Release/../../lib/libvips.so.42
No symbol table info available.
#5  0x00007f719439566c in vips::VImage::call_option_string(char const*, char const*, vips::VOption*) ()
   from /home/vilson/src/noflo/noflo-sharp/node_modules/sharp/build/Release/../../lib/libvips-cpp.so.42
---Type <return> to continue, or q <return> to quit---
No symbol table info available.
#6  0x00007f7194395c36 in vips::VImage::new_from_file(char const*, vips::VOption*) ()
   from /home/vilson/src/noflo/noflo-sharp/node_modules/sharp/build/Release/../../lib/libvips-cpp.so.42
No symbol table info available.
#7  0x00007f71945b6fc2 in MetadataWorker::Execute() ()
   from /home/vilson/src/noflo/noflo-sharp/node_modules/sharp/build/Release/sharp.node
No symbol table info available.
#8  0x0000000000fac641 in worker (arg=arg@entry=0x0) at ../deps/uv/src/threadpool.c:95
        w = 0x2771740
        q = 0x2771758
#9  0x0000000000fbb279 in uv__thread_start (arg=<optimized out>)
    at ../deps/uv/src/unix/thread.c:49
        ctx_p = <optimized out>
        ctx = {entry = 0xfac5a0 <worker>, arg = 0x0}
#10 0x00007f7196ba0182 in start_thread (arg=0x7f717c22e700) at pthread_create.c:312
        __res = <optimized out>
        pd = 0x7f717c22e700
        now = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140125390694144, -6163230216398523673,
                0, 0, 140125390694848, 140125390694144, 6094837594223063783,
                6094746548175287015}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0,
              0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
---Type <return> to continue, or q <return> to quit---
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#11 0x00007f71968cd47d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
No locals.
(gdb)

Environment variable are pointing to sharp’s:

echo $LD_LIBRARY_PATH
./node_modules/sharp/lib

If there’s more information I should provide, please just ask.

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Comments: 27 (10 by maintainers)

Most upvoted comments

Thanks to @jonnor suggestion we used a workaround: we updated libvips to 8.3.1 on this buildpack/bundle and we’re using it in both Travis/Heroku. In this way, both node-canvas and sharp are using the same “global” GLib.

(At the same time we removed ImageMagick and included giflib/libsvgr to match dependencies for sharp 0.15 and to be free from IM vulnerability)