cinu

#49863: fix: prevent GBytes leak in GdkPixbufFromSkBitmap on Linux/GTK

Merged
Created: Feb 19, 2026, 1:09:26 AM
Merged: Feb 20, 2026, 2:00:46 PM
6 comments
Target: main

Description of Change

g_bytes_new() was called inline as an argument to gdk_pixbuf_new_from_bytes(), which per GTK docs does not take ownership of the GBytes - it adds its own internal reference. The caller's GBytes* was never stored or unreffed, leaking 4 * width * height bytes of pixel data on every call.

This is most impactful when calling Tray.setImage() repeatedly (e.g., for animated tray icons), causing continuously growing process memory that is never reclaimed.

Internally, gdk_pixbuf_new_from_bytes() calls g_object_new() with the "pixel-bytes" construct property. In gdk_pixbuf_set_property(), the PROP_PIXEL_BYTES case stores the bytes via g_value_dup_boxed(), which calls g_boxed_copy() -> _g_type_boxed_copy() -> the registered copy function. Since G_TYPE_BYTES is registered as G_DEFINE_BOXED_TYPE(GBytes, g_bytes, g_bytes_ref, g_bytes_unref), the copy function is g_bytes_ref(), incrementing the refcount.

Simple app that sets tray icon (1024x1024) 100 times:
Before fix: RSS 633.07 MB
After fix: RSS 282.91 MB

Checklist

  • PR description included
  • I have built and tested this PR

Release Notes

Notes: Fix memory leak when setting icons on Linux/GTK

Backports

38-x-y
Merged
PR Number
#49897
Merged At
Feb 21, 2026, 10:11:53 AM
Released In
v38.8.4
Release Date
Feb 24, 2026, 10:03:23 AM
39-x-y
Merged
PR Number
#49896
Merged At
Feb 20, 2026, 4:58:01 PM
Released In
v39.7.0
Release Date
Feb 24, 2026, 4:00:33 PM
40-x-y
Merged
PR Number
#49898
Merged At
Feb 20, 2026, 6:10:35 PM
Released In
v40.6.1
Release Date
Feb 24, 2026, 10:03:37 AM
41-x-y
Merged
PR Number
#49895
Merged At
Feb 20, 2026, 4:58:05 PM
Released In
v41.0.0-beta.5
Release Date
Feb 23, 2026, 7:31:37 AM

Semver Impact

Major
Breaking changes
Minor
New features
Patch
Bug fixes
None
Docs, tests, etc.

Semantic Versioning helps users understand the impact of updates:

  • Major (X.y.z): Breaking changes that may require code modifications
  • Minor (x.Y.z): New features that maintain backward compatibility
  • Patch (x.y.Z): Bug fixes that don't change the API
  • None: Changes that don't affect using facing parts of Electron