delete sharp instance

[caibao-9]

Question about an existing feature

how to delete sharp instance? Does not occupy memory space

[lovell]

Like all JavaScript Objects in Node.js, when a sharp instance falls out of scope it will become eligible for garbage collection.

[caibao-9]

@lovell
How can I manually delete the sharp instance,
my current usage scenario requires me to do this.

[lovell]

You can set a JavaScript variable to null as a hint to the garbage collector that its previous value is no longer required. (This is a JavaScript concept unrelated to sharp.)

var sharpInstance = sharp(...)...;

...

sharpInstance = null;

[lovell]

I suspect the question you're going to ask next is about memory consumption as reported via resident set size (RSS). If so, please ensure you've read and understand everything discussed in #955

[caibao-9]

@lovell
Do you know why I made this mistake when I used sharp？
(process:126554): GLib-CRITICAL **: 10:03:08.513: g_datalist_id_set_data_full: assertion 'key_id > 0' failed
(process:126554): GLib-CRITICAL **: 10:03:08.516: g_datalist_id_set_data_full: assertion 'key_id > 0' failed
(process:126554): GLib-CRITICAL **: 10:03:08.531: g_datalist_id_set_data_full: assertion 'key_id > 0' failed
(process:126554): GLib-CRITICAL **: 10:03:08.551: g_datalist_id_set_data_full: assertion 'key_id > 0' failed
(process:126554): GLib-CRITICAL **: 10:03:08.567: g_datalist_id_set_data_full: assertion 'key_id > 0' failed
(process:126554): GLib-CRITICAL **: 10:03:08.587: g_datalist_id_set_data_full: assertion 'key_id > 0' failed
(process:126554): GLib-CRITICAL **: 10:03:08.589: g_datalist_id_set_data_full: assertion 'key_id > 0' failed
(process:126554): GLib-CRITICAL **: 10:03:08.596: g_datalist_id_set_data_full: assertion 'key_id > 0' failed
(process:126554): GLib-CRITICAL **: 10:03:08.622: g_datalist_id_set_data_full: assertion 'key_id > 0' failed
(process:126554): GLib-CRITICAL **: 10:03:08.642: g_datalist_id_set_data_full: assertion 'key_id > 0' failed
(process:126554): GLib-CRITICAL **: 10:03:08.642: g_datalist_id_set_data_full: assertion 'key_id > 0' failed
(process:126554): GLib-CRITICAL **: 10:03:08.644: g_datalist_id_set_data_full: assertion 'key_id > 0' failed
(process:126554): GLib-CRITICAL **: 10:03:08.687: g_datalist_id_set_data_full: assertion 'key_id > 0' failed
(process:126554): GLib-CRITICAL **: 10:03:08.695: g_datalist_id_set_data_full: assertion 'key_id > 0' failed
(process:126554): GLib-CRITICAL **: 10:03:08.699: g_datalist_id_set_data_full: assertion 'key_id > 0' failed
(process:126554): GLib-CRITICAL **: 10:03:08.706: g_datalist_id_set_data_full: assertion 'key_id > 0' failed
MEMORY-ERROR: [126554]: GSlice: assertion failed: sinfo->n_allocated > 0

[lovell]

The latest sharp provides the latest version of glib that does not use GSlice. You've provided very little information in this issue, but my best guess would be that you're using a globally-installed libvips with an outdated glib dependency, or perhaps you're using Electron (e.g. electron/electron#38048).

If you still require help, please create a standalone repo with minimal code that allows someone else to reproduce.

[shamsup]

Is there a fix for this in electron? It frequently crashes my app in development. The linked electron issue is marked as resolved, but seems unrelated to sharp in the end.

sharp 0.32.6 (has been happening since at least 0.30 that we started on)
electron: 25.8.4 (has happened as far back as electron 20)

[lovell]

@shamsup Sharp provides the latest glib, which no longer uses the gslice memory allocator (this is a good thing). I suspect Electron either ships with or relies on an older version of glib that does use gslice. You should be able to switch off gslice by setting the G_SLICE=always-malloc environment variable.

[kotasudhakar]

Is there a fix for this in electron? It frequently crashes my app in development. The linked electron issue is marked as resolved, but seems unrelated to sharp in the end.

sharp 0.32.6 (has been happening since at least 0.30 that we started on) electron: 25.8.4 (has happened as far back as electron 20)

I faced this memory issue too in electron when i upgraded to using sharp 0.32.6.
Switched to older version of sharp -> "sharp": "^0.31.3", which worked for and issue is now resolved

[shamsup]

@shamsup Sharp provides the latest glib, which no longer uses the gslice memory allocator (this is a good thing). I suspect Electron either ships with or relies on an older version of glib that does use gslice. You should be able to switch off gslice by setting the G_SLICE=always-malloc environment variable.

This is great for our development environment, thanks! Is there anything special we need to do to ensure our application runs with this flag on users' machines, or does it get locked in at build time? Is this a Linux only issue, or does it affect macOS and Windows as well? I couldn't find anything in electron's docs about this variable at all.

I faced this memory issue too in electron when i upgraded to using sharp 0.32.6.
Switched to older version of sharp -> "sharp": "^0.31.3", which worked for and issue is now resolved

Unfortunately, we have experienced it with much older versions as well, but we are doing a LOT with sharp, sometimes hundreds of operations per minute.

[lovell]

@shamsup G_SLICE is an environment variable read at runtime and it will need to be set before Electron starts, so I'm unsure how best to do that for end users.

[lovell]

I hope this information helped. Please feel free to re-open with more details if further assistance is required.