You are not logged in.

#1 2025-09-27 18:22:03

IDKWhatToPutHere
Member
Registered: 2025-05-06
Posts: 12

Rhythmbox crashing - Fatal glibc error

I listen to music with Rhythmbox; a few times recently, it has crashed, each time with the message:

Fatal glibc error: malloc.c:2610 (sysmalloc): assertion failed: (old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)

Does anyone know what's going on here - is it a bug in glibc or Rhythmbox (as it seems to be), or just a version mismatch or something? Rhythmbox is 3.4.8-4, glibc is 2.42+r17+gd7274d718e6f-1. It also might be an issue in Glycin (GNOME's image tools), because some files called gdk-pixbuf-glycin-tmp.XXXXXX containing some album covers appeared in /tmp, and Glycin is slightly outdated (I've updated it now, and Rhythmbox has no crashed while I'm writing this post (nevermind...)), but I have no idea. Maybe I should just move to a different music player!

Offline

#2 2025-09-27 22:18:48

IDKWhatToPutHere
Member
Registered: 2025-05-06
Posts: 12

Re: Rhythmbox crashing - Fatal glibc error

Huh, when I put it under the watchful eye of gdb so I can get a backtrace when it crashes, it doesn't. Probably just a coincidence.

Last edited by IDKWhatToPutHere (2025-09-27 22:19:02)

Offline

#3 2025-09-27 22:37:52

IDKWhatToPutHere
Member
Registered: 2025-05-06
Posts: 12

Re: Rhythmbox crashing - Fatal glibc error

Nevermind! Here it is. Maybe somebody can make sense of this. As I suspected, it seems to have *something* to do with loading the album covers?

#0  __GI_abort () at abort.c:76
#1  0x00007ffff7026613 in __libc_message_impl (fmt=fmt@entry=0x7ffff71b4355 "%s\n") at ../sysdeps/posix/libc_fatal.c:138
#2  0x00007ffff70a2d65 in malloc_printerr (str=str@entry=0x7ffff71b7890 "malloc(): invalid next size (unsorted)") at malloc.c:5892
#3  0x00007ffff70a617c in _int_malloc (av=av@entry=0x7fff20000030, bytes=bytes@entry=4160) at malloc.c:4214
#4  0x00007ffff70a6d40 in __libc_calloc2 (sz=4160) at malloc.c:3864
#5  0x00007ffff7d5e593 in g_malloc0 (n_bytes=n_bytes@entry=4160) at ../glib/glib/gmem.c:133
#6  0x00007ffff7256fdb in gdk_pixbuf_loader_init (loader=0x7fff20002c50) at ../gdk-pixbuf/gdk-pixbuf/gdk-pixbuf-loader.c:229
#7  0x00007ffff7cd7a69 in g_type_create_instance (type=<optimized out>) at ../glib/gobject/gtype.c:1900
#8  0x00007ffff7cbcc05 in g_object_new_internal (class=0x5555558c0800, params=0x0, n_params=0) at ../glib/gobject/gobject.c:2665
#9  0x00007ffff7cbe2a7 in g_object_new_internal (class=<optimized out>, params=<optimized out>, n_params=<optimized out>) at ../glib/gobject/gobject.c:2662
#10 g_object_new_with_properties (object_type=<optimized out>, n_properties=<optimized out>, names=names@entry=0x0, values=values@entry=0x0) at ../glib/gobject/gobject.c:2827
#11 0x00007ffff7cbf2e2 in g_object_new (object_type=<optimized out>, first_property_name=first_property_name@entry=0x0) at ../glib/gobject/gobject.c:2476
#12 0x00007ffff725f94c in gdk_pixbuf_loader_new () at ../gdk-pixbuf/gdk-pixbuf/gdk-pixbuf-loader.c:616
#13 0x00007ffff7ec1437 in load_external_art_cb (store=<optimized out>, value=0x7fff20005d60, shell=<optimized out>) at ../rhythmbox/shell/rb-shell.c:350
#14 0x00007ffff657fac6 in ffi_call_unix64 () at ../src/x86/unix64.S:104
#15 0x00007ffff657c76b in ffi_call_int (cif=cif@entry=0x7fff277fd1e0, fn=fn@entry=0x7ffff7ec13d0 <load_external_art_cb>, rvalue=<optimized out>, rvalue@entry=0x7fff277fd160, avalue=avalue@entry=0x7fff277fd120, closure=closure@entry=0x0) at ../src/x86/ffi64.c:676
#16 0x00007ffff657f06e in ffi_call (cif=cif@entry=0x7fff277fd1e0, fn=fn@entry=0x7ffff7ec13d0 <load_external_art_cb>, rvalue=rvalue@entry=0x7fff277fd160, avalue=avalue@entry=0x7fff277fd120) at ../src/x86/ffi64.c:713
#17 0x00007ffff7cb12e0 in g_cclosure_marshal_generic (closure=<optimized out>, return_gvalue=<optimized out>, n_param_values=<optimized out>, param_values=<optimized out>, invocation_hint=<optimized out>, marshal_data=<optimized out>) at ../glib/gobject/gclosure.c:1624
#18 0x00007ffff7caa97c in g_closure_invoke (closure=0x555555782420, return_value=0x7fff277fd3d0, n_param_values=2, param_values=0x7fff277fd460, invocation_hint=0x7fff277fd3b0) at ../glib/gobject/gclosure.c:916
#19 0x00007ffff7cc9aab in signal_emit_unlocked_R (node=node@entry=0x7fff277fd590, detail=detail@entry=0, instance=instance@entry=0x7fffd4003b70, emission_return=emission_return@entry=0x7fff277fd610, instance_and_params=instance_and_params@entry=0x7fff277fd460) at ../glib/gobject/gsignal.c:3903
#20 0x00007ffff7ccb2db in signal_emit_valist_unlocked (instance=instance@entry=0x7fffd4003b70, signal_id=signal_id@entry=301, detail=detail@entry=0, var_args=var_args@entry=0x7fff277fd6f0) at ../glib/gobject/gsignal.c:3548
#21 0x00007ffff7ccbd89 in g_signal_emit_valist (instance=0x7fffd4003b70, signal_id=301, detail=0, var_args=var_args@entry=0x7fff277fd6f0) at ../glib/gobject/gsignal.c:3278
#22 0x00007ffff7ccbe44 in g_signal_emit (instance=instance@entry=0x7fffd4003b70, signal_id=<optimized out>, detail=detail@entry=0) at ../glib/gobject/gsignal.c:3598
#23 0x00007ffff7f54a25 in do_load_request (result=<optimized out>, object=0x7fffd4003b70, cancel=<optimized out>) at ../rhythmbox/metadata/rb-ext-db.c:669
#24 0x00007ffff6ec4051 in run_in_thread (job=<optimized out>, c=0x0, _data=0x5555573a0ac0) at ../glib/gio/gsimpleasyncresult.c:899
#25 0x00007ffff6ea6c4a in io_job_thread (task=<optimized out>, source_object=<optimized out>, task_data=0x555555ee8cf0, cancellable=<optimized out>) at ../glib/gio/gioscheduler.c:75
#26 0x00007ffff6edc600 in g_task_thread_pool_thread (thread_data=0x555555e42a50, pool_data=<optimized out>) at ../glib/gio/gtask.c:1585
#27 0x00007ffff7d91243 in g_thread_pool_thread_proxy (data=<optimized out>) at ../glib/glib/gthreadpool.c:336
#28 0x00007ffff7d8f87c in g_thread_proxy (data=0x7fffdc001e70) at ../glib/glib/gthread.c:893
#29 0x00007ffff70969cb in start_thread (arg=<optimized out>) at pthread_create.c:448
#30 0x00007ffff711aa0c in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Last edited by IDKWhatToPutHere (2025-09-27 22:38:17)

Offline

#4 2025-09-28 01:06:25

correctmost
Member
Registered: 2024-01-20
Posts: 18

Re: Rhythmbox crashing - Fatal glibc error

Do you have the "cover art search" plug-in enabled?  When I try to enable the plug-in on a new installation, I get a libpeas warning:

Failed to load module 'python3loader': /usr/lib/libpeas-1.0/loaders/libpython3loader.so: cannot open shared object file: No such file or directory

What versions of libpeas and python-gobject do you have installed?  If the plug-in works for you, you might not have the latest versions of those packages: https://gitlab.archlinux.org/archlinux/ … -/issues/3

Offline

#5 2025-09-28 05:24:03

Spriteman
Member
Registered: 2022-08-21
Posts: 2

Re: Rhythmbox crashing - Fatal glibc error

I had to downgrade gdk-pixbuf2 to version 2.42.12 to make Rhythmbox work fine with cover arts inside MP3s. Had crashes without version 2.42.12.

Offline

#6 2025-09-28 09:59:54

IDKWhatToPutHere
Member
Registered: 2025-05-06
Posts: 12

Re: Rhythmbox crashing - Fatal glibc error

> Do you have the "cover art search" plug-in enabled?
No, I have no plugins enabled.

> What versions of libpeas and python-gobject do you have installed?
1.36.0-7 and 3.54..2-2, resp.

> I had to downgrade gdk-pixbuf2 to version 2.42.12
I'll try that (it's currently at 2.44.2).

Last edited by IDKWhatToPutHere (2025-09-28 10:01:32)

Offline

#7 2025-09-28 11:05:38

IDKWhatToPutHere
Member
Registered: 2025-05-06
Posts: 12

Re: Rhythmbox crashing - Fatal glibc error

It still crashes.

Offline

#8 2025-09-28 11:08:05

IDKWhatToPutHere
Member
Registered: 2025-05-06
Posts: 12

Re: Rhythmbox crashing - Fatal glibc error

I'll see if I can build gdk-pixbuf-2 with AddressSanitizer to see whether it's actually a heap buffer overflow, as "malloc(): invalid next size (unsorted)" seems to indicate. If so, I suppose I'll contact GNOME about this.

Offline

#9 2025-09-28 12:18:30

IDKWhatToPutHere
Member
Registered: 2025-05-06
Posts: 12

Re: Rhythmbox crashing - Fatal glibc error

Hm, I don't see any asan logs, but maybe I just built it wrong. I get a different backtrace this time, actually mentioning the failing assert:

#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1  0x00007ffff7098a13 in __pthread_kill_internal (threadid=<optimized out>, signo=6) at pthread_kill.c:89
#2  0x00007ffff703e410 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3  0x00007ffff702557a in __GI_abort () at abort.c:77
#4  0x00007ffff7026613 in __libc_message_impl (fmt=fmt@entry=0x7ffff71b5b00 "Fatal glibc error: %s:%s (%s): assertion failed: %s\n") at ../sysdeps/posix/libc_fatal.c:138
#5  0x00007ffff7035ed6 in __libc_assert_fail (assertion=assertion@entry=0x7ffff71b7600 "(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)", file=file@entry=0x7ffff71b2021 "malloc.c", line=line@entry=2610, function=function@entry=0x7ffff71b7f20 <__PRETTY_FUNCTION__.8> "sysmalloc") at __libc_assert_fail.c:31
#6  0x00007ffff70a58e2 in sysmalloc (nb=nb@entry=1078208, av=0x7fff84000030) at malloc.c:2610
#7  0x00007ffff70a6933 in _int_malloc (av=av@entry=0x7fff84000030, bytes=bytes@entry=1078200) at malloc.c:4617
#8  0x00007ffff70a6d40 in __libc_calloc2 (sz=1078200) at malloc.c:3864
#9  0x00007ffff7250d8d in gdk_pixbuf_new () at /usr/lib/libgdk_pixbuf-2.0.so.0
#10 0x00007ffff726ae2c in ??? () at /usr/lib/libgdk_pixbuf-2.0.so.0
#11 0x00007ffff724ed45 in ??? () at /usr/lib/libgdk_pixbuf-2.0.so.0
#12 0x00007ffff7253bf9 in gdk_pixbuf_loader_write () at /usr/lib/libgdk_pixbuf-2.0.so.0
#13 0x00007ffff7ec1451 in load_external_art_cb (store=<optimized out>, value=<optimized out>, shell=<optimized out>) at ../rhythmbox/shell/rb-shell.c:351
#14 0x00007ffff6571ac6 in ffi_call_unix64 () at ../src/x86/unix64.S:104
#15 0x00007ffff656e76b in ffi_call_int (cif=cif@entry=0x7fff967fb3e0, fn=fn@entry=0x7ffff7ec13d0 <load_external_art_cb>, rvalue=<optimized out>, rvalue@entry=0x7fff967fb360, avalue=avalue@entry=0x7fff967fb320, closure=closure@entry=0x0) at ../src/x86/ffi64.c:676
#16 0x00007ffff657106e in ffi_call (cif=cif@entry=0x7fff967fb3e0, fn=fn@entry=0x7ffff7ec13d0 <load_external_art_cb>, rvalue=rvalue@entry=0x7fff967fb360, avalue=avalue@entry=0x7fff967fb320) at ../src/x86/ffi64.c:713
#22 0x00007ffff7ccbe44 in <emit signal 'load' on instance ???> (instance=instance@entry=0x55555582aef0, signal_id=<optimized out>, detail=detail@entry=0) at ../glib/gobject/gsignal.c:3598
    #17 0x00007ffff7cb12e0 in g_cclosure_marshal_generic (closure=<optimized out>, return_gvalue=<optimized out>, n_param_values=<optimized out>, param_values=<optimized out>, invocation_hint=<optimized out>, marshal_data=<optimized out>) at ../glib/gobject/gclosure.c:1624
    #18 0x00007ffff7caa97c in g_closure_invoke (closure=0x5555557992a0, return_value=0x7fff967fb5d0, n_param_values=2, param_values=0x7fff967fb660, invocation_hint=0x7fff967fb5b0) at ../glib/gobject/gclosure.c:916
    #19 0x00007ffff7cc9aab in signal_emit_unlocked_R (node=node@entry=0x7fff967fb790, detail=detail@entry=0, instance=instance@entry=0x55555582aef0, emission_return=emission_return@entry=0x7fff967fb810, instance_and_params=instance_and_params@entry=0x7fff967fb660) at ../glib/gobject/gsignal.c:3903
    #20 0x00007ffff7ccb2db in signal_emit_valist_unlocked (instance=instance@entry=0x55555582aef0, signal_id=signal_id@entry=301, detail=detail@entry=0, var_args=var_args@entry=0x7fff967fb8f0) at ../glib/gobject/gsignal.c:3548
    #21 0x00007ffff7ccbd89 in g_signal_emit_valist (instance=0x55555582aef0, signal_id=301, detail=0, var_args=var_args@entry=0x7fff967fb8f0) at ../glib/gobject/gsignal.c:3278
#23 0x00007ffff7f54a25 in do_load_request (result=<optimized out>, object=0x55555582aef0, cancel=<optimized out>) at ../rhythmbox/metadata/rb-ext-db.c:669
#24 0x00007ffff6ec4051 in run_in_thread (job=<optimized out>, c=0x0, _data=0x555556dfef40) at ../glib/gio/gsimpleasyncresult.c:899
#25 0x00007ffff6ea6c4a in io_job_thread (task=<optimized out>, source_object=<optimized out>, task_data=0x555556ed8b90, cancellable=<optimized out>) at ../glib/gio/gioscheduler.c:75
#26 0x00007ffff6edc600 in g_task_thread_pool_thread (thread_data=0x7fff84001340, pool_data=<optimized out>) at ../glib/gio/gtask.c:1585
#27 0x00007ffff7d91243 in g_thread_pool_thread_proxy (data=<optimized out>) at ../glib/glib/gthreadpool.c:336
#28 0x00007ffff7d8f87c in g_thread_proxy (data=0x7fffe8001ee0) at ../glib/glib/gthread.c:893
#29 0x00007ffff70969cb in start_thread (arg=<optimized out>) at pthread_create.c:448
#30 0x00007ffff711aa0c in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Offline

#10 2025-10-03 20:13:17

lotan
Member
Registered: 2025-10-03
Posts: 8

Re: Rhythmbox crashing - Fatal glibc error

I had a similar/maybe the same problem:

rhythmbox -d

would crash on some, seemingly random songs.
However, on that song the crash was reproducible every time.

Error messages would include:

double free or corruption (!prev)

and

malloc(): invalid next size (unsorted)

Each time rhythmbox would crash (SIGABRT) the backtrace would contain libc and glib2 libraries.

So I downgraded

glib2

to version

2.84.4-2 (2.85.x would still crash)

So far so good. No more crashes.

Last edited by lotan (2025-10-03 20:13:35)

Offline

#11 2025-10-03 20:49:37

seth
Member
From: Don't DM me only for attention
Registered: 2012-09-03
Posts: 68,992

Re: Rhythmbox crashing - Fatal glibc error

pacman -Qm
pacman -Qikk libffi

Offline

#12 2025-10-03 23:39:50

Shino
Member
From: Germany
Registered: 2015-02-01
Posts: 106

Re: Rhythmbox crashing - Fatal glibc error

I have the same bug as the TO.

% rhythmbox
Fatal glibc error: malloc.c:2610 (sysmalloc): assertion failed: (old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)
[1]    63788 IOT instruction (core dumped)  rhythmbox

And

% rhythmbox
malloc(): invalid next size (unsorted)
[1]    64949 IOT instruction (core dumped)  rhythmbox

pacman -Qm only lists my AUR packets and my own tools I built packages for:

pacman -Qm
aeskulap 0.2.2beta2+r8+ge710562-2
ckb-next-git 1:0.6.2.r40.gb2fa1708-1
coz-git r565.7bb77a7-1
epson-jpn-fonts 1.0-1
foldingathome 8.4.9-1
gds-render v1.2.3_1_1_gc9b0783-1
it87-dkms-git 287.4bff981-1
jlink-software-and-documentation 63:8.54-1
libglade 2.6.4-9
lm_sensors-it87-git 1:3.6.0.r41.g31d1f125-4
ncurses5-compat-libs 6.5-2
ozone 30:3.38g-0
patchelfcrc v1.0.0_rc7-1
python-nbstripout 0.8.1-1
 pacman -Qikk libffi

Name            : libffi
Version         : 3.5.2-1
Description     : Portable foreign function interface library
Architecture    : x86_64
URL             : https://sourceware.org/libffi/
Licenses        : MIT
Groups          : None
Provides        : libffi.so=8-64
Depends On      : glibc
Optional Deps   : None
Required By     : chromium  electron35  electron37  ghc-libs  gjs  glib2  guile  libgirepository  libp11-kit  llvm-libs  python  python-gobject  rocm-llvm  wayland
Optional For    : None
Conflicts With  : None
Replaces        : None
Installed Size  : 102.59 KiB
Packager        : David Runge <dvzrv@archlinux.org>
Build Date      : Sat 02 Aug 2025 10:41:02 PM CEST
Install Date    : Tue 09 Sep 2025 11:40:24 PM CEST
Install Reason  : Installed as a dependency for another package
Install Script  : No
Validated By    : Signature

Offline

#13 2025-10-04 07:28:35

lotan
Member
Registered: 2025-10-03
Posts: 8

Re: Rhythmbox crashing - Fatal glibc error

# pacman -Qm
aliza 2.7.3-1
aliza-debug 2.7.3-1
ampache-mediaserver-interface r18.233a872-1
dbus-codegen-rust-git 0.10.0.r1084.g366a6dc-1
downgrade 11.5.4-1
dracut-hook 0.5.3-1
google-chrome 141.0.7390.54-1
http-parser 2.9.4-2
kpcli 4.1.3-1
lib32-gnome-themes-extra 3.28+r6+g45b1d457-1
libjson-rpc-cpp-git 1.1.0.r0.gc5387ba-1
nautilus-sendto 3.8.6+28+gc87aac4-3
nautilus-sendto-debug 3.8.6+28+gc87aac4-3
perl-boolean 0.46-1
perl-crypt-argon2 0.030-20
perl-crypt-rijndael 1.16-3
perl-dist-build 0.020-3
perl-extutils-builder 0.017-2
perl-extutils-builder-compiler 0.028-2
perl-extutils-hascompiler 0.025-2
perl-file-kdbx 0.906-1
perl-file-keepass 2.03-4
perl-file-sharedir-tiny 0.001-2
perl-iterator-simple 0.07-1
perl-term-shellui 0.92-5
perl-xml-treepp 0.43-3
python-async-timeout 5.0.1-1
qt5-datavis3d 5.15.17-1
rar 7.12-1
rar-debug 7.12-1
reiserfsprogs 3.6.27-5
scrub 2.6.1-1
ssmtp 2.64-19
ssmtp-debug 2.64-19
sweethome3d-furniture-library 2.2-1
tempered-git r100.e77ee06-1
testdisk-wip 7.2-4
tvheadend 4.2.8-8
tvheadend-debug 4.2.8-8
urlencode 1.6.0-1
urlencode-debug 1.6.0-1
wireguard-dkms 1.0.20220627-1
xerox-workcentre-6515-6510 5.662.0.0-4
yay 12.5.2-2
yay-debug 12.5.2-2
zoom 6.6.0-1
# pacman -Qikk libffi
Name            : libffi
Version         : 3.5.2-1
Description     : Portable foreign function interface library
Architecture    : x86_64
URL             : https://sourceware.org/libffi/
Licenses        : MIT
Groups          : None
Provides        : libffi.so=8-64
Depends On      : glibc
Optional Deps   : None
Required By     : chromium  electron34  electron35  electron36  electron37
                  ghc-libs  gjs  glib2  gobject-introspection  guile
                  intel-oneapi-openmp  lib32-libffi  libgirepository
                  libp11-kit  llvm-libs  python  python-gobject  wayland
Optional For    : None
Conflicts With  : None
Replaces        : None
Installed Size  : 102.59 KiB
Packager        : David Runge <dvzrv@archlinux.org>
Build Date      : Sat 02 Aug 2025 22:41:02 CEST
Install Date    : Sat 04 Oct 2025 08:53:21 CEST
Install Reason  : Installed as a dependency for another package
Install Script  : No
Validated By    : Signature

libffi: 25 total files, 0 altered files

Offline

#14 2025-10-04 08:46:40

seth
Member
From: Don't DM me only for attention
Registered: 2012-09-03
Posts: 68,992

Re: Rhythmbox crashing - Fatal glibc error

It's not libffi and neither foreign package list includes suspicious clients - might be a stealth ABI break in glib2 and rhythmbox simply a rebuild, you can test this by building it against the updated glib2, https://wiki.archlinux.org/title/Arch_build_system
(The crash is in a threaded memory allocation and apparently the critical element is glib2 and not gdk-pixbuf2)

Offline

#15 2025-10-04 09:04:08

Shino
Member
From: Germany
Registered: 2015-02-01
Posts: 106

Re: Rhythmbox crashing - Fatal glibc error

I rebuilt the rhythmbox package on my PC (simply cloned the sources from the package repo and hit makepkg). Doesn't help, rhythmbox still crashes.

(gdb) backtrace 
#0  0x00007ffff709894c in ?? () from /usr/lib/libc.so.6
#1  0x00007ffff703e410 in raise () from /usr/lib/libc.so.6
#2  0x00007ffff702557a in abort () from /usr/lib/libc.so.6
#3  0x00007ffff7026613 in ?? () from /usr/lib/libc.so.6
#4  0x00007ffff70a2d65 in ?? () from /usr/lib/libc.so.6
#5  0x00007ffff70a617c in ?? () from /usr/lib/libc.so.6
#6  0x00007ffff70a6d40 in ?? () from /usr/lib/libc.so.6
#7  0x00007ffff7d5e593 in g_malloc0 () from /usr/lib/libglib-2.0.so.0
#8  0x00007ffff7256fdb in ?? () from /usr/lib/libgdk_pixbuf-2.0.so.0
#9  0x00007ffff7cd7a69 in g_type_create_instance () from /usr/lib/libgobject-2.0.so.0
#10 0x00007ffff7cbcc05 in ?? () from /usr/lib/libgobject-2.0.so.0
#11 0x00007ffff7cbe2a7 in g_object_new_with_properties () from /usr/lib/libgobject-2.0.so.0
#12 0x00007ffff7cbf2e2 in g_object_new () from /usr/lib/libgobject-2.0.so.0
#13 0x00007ffff7ec1437 in ?? () from /usr/lib/librhythmbox-core.so.10
#14 0x00007ffff656bac6 in ?? () from /usr/lib/libffi.so.8
#15 0x00007ffff656876b in ?? () from /usr/lib/libffi.so.8
#16 0x00007ffff656b06e in ffi_call () from /usr/lib/libffi.so.8
#17 0x00007ffff7cb12e0 in g_cclosure_marshal_generic () from /usr/lib/libgobject-2.0.so.0
#18 0x00007ffff7caa97c in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#19 0x00007ffff7cc9aab in ?? () from /usr/lib/libgobject-2.0.so.0
#20 0x00007ffff7ccb2db in ?? () from /usr/lib/libgobject-2.0.so.0
#21 0x00007ffff7ccbd89 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#22 0x00007ffff7ccbe44 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#23 0x00007ffff7f54a85 in ?? () from /usr/lib/librhythmbox-core.so.10
#24 0x00007ffff6ec4051 in ?? () from /usr/lib/libgio-2.0.so.0
#25 0x00007ffff6ea6c4a in ?? () from /usr/lib/libgio-2.0.so.0
#26 0x00007ffff6edc600 in ?? () from /usr/lib/libgio-2.0.so.0
#27 0x00007ffff7d91243 in ?? () from /usr/lib/libglib-2.0.so.0
#28 0x00007ffff7d8f87c in ?? () from /usr/lib/libglib-2.0.so.0
#29 0x00007ffff70969cb in ?? () from /usr/lib/libc.so.6
#30 0x00007ffff711aa0c in ?? () from /usr/lib/libc.so.6

Last edited by Shino (2025-10-04 10:11:35)

Offline

#16 2025-10-04 10:25:52

lotan
Member
Registered: 2025-10-03
Posts: 8

Re: Rhythmbox crashing - Fatal glibc error

Same here. Recompile of rhythmbox didn't help.

I tried to recompile rhythmbox not because I don't trust Shino but because I thought there's still a chance that I may have a different issue.

Last edited by lotan (2025-10-04 10:26:06)

Offline

#17 2025-10-04 10:47:20

Shino
Member
From: Germany
Registered: 2015-02-01
Posts: 106

Re: Rhythmbox crashing - Fatal glibc error

Just as a joke, I know it's not a real solution. But for me it can be fixed the same way all enterprise software is fixed:

#define _GNU_SOURCE
#include <dlfcn.h>
#include <pthread.h>
#include <stdlib.h>

#define FREE_DELAY 100000

static void *free_delay_queue[FREE_DELAY];
static int free_delay_pos;
static void (*orig_free)(void *) = NULL;
static void *(*orig_malloc)(size_t) = NULL;
static pthread_mutex_t free_delay_mutex = PTHREAD_MUTEX_INITIALIZER;

void free(void *ptr)
{
	if (!ptr)
		return;
	pthread_mutex_lock(&free_delay_mutex);
	if (!orig_free)
		orig_free = dlsym(RTLD_NEXT, "free");
	orig_free(free_delay_queue[free_delay_pos]);
	free_delay_queue[free_delay_pos] = ptr;
	free_delay_pos++;
	free_delay_pos %= FREE_DELAY;
	pthread_mutex_unlock(&free_delay_mutex);
}

void *malloc(size_t s)
{
	pthread_mutex_lock(&free_delay_mutex);
	if (!orig_malloc)
		orig_malloc = dlsym(RTLD_NEXT, "malloc");
	pthread_mutex_unlock(&free_delay_mutex);
	return orig_malloc(s * 2 + 0x100);
}

Compile with

gcc -o enterprise_malloc.so --shared enterprise_malloc.c

And start rhythmbox by LD_PRELOADing this:

LD_PRELOAD=./enterprise_malloc.so rhythmbox

At least I can listen to music again...

Offline

#18 2025-10-04 11:34:13

lotan
Member
Registered: 2025-10-03
Posts: 8

Re: Rhythmbox crashing - Fatal glibc error

Shino wrote:

Just as a joke, I know it's not a real solution. But for me it can be fixed the same way all enterprise software is fixed:

#define _GNU_SOURCE
#include <dlfcn.h>
#include <pthread.h>
#include <stdlib.h>

#define FREE_DELAY 100000

static void *free_delay_queue[FREE_DELAY];
static int free_delay_pos;
static void (*orig_free)(void *) = NULL;
static void *(*orig_malloc)(size_t) = NULL;
static pthread_mutex_t free_delay_mutex = PTHREAD_MUTEX_INITIALIZER;

void free(void *ptr)
{
	if (!ptr)
		return;
	pthread_mutex_lock(&free_delay_mutex);
	if (!orig_free)
		orig_free = dlsym(RTLD_NEXT, "free");
	orig_free(free_delay_queue[free_delay_pos]);
	free_delay_queue[free_delay_pos] = ptr;
	free_delay_pos++;
	free_delay_pos %= FREE_DELAY;
	pthread_mutex_unlock(&free_delay_mutex);
}

void *malloc(size_t s)
{
	pthread_mutex_lock(&free_delay_mutex);
	if (!orig_malloc)
		orig_malloc = dlsym(RTLD_NEXT, "malloc");
	pthread_mutex_unlock(&free_delay_mutex);
	return orig_malloc(s * 2 + 0x100);
}

Compile with

gcc -o enterprise_malloc.so --shared enterprise_malloc.c

And start rhythmbox by LD_PRELOADing this:

LD_PRELOAD=./enterprise_malloc.so rhythmbox

At least I can listen to music again...

That's a cool idea.
Thanks a lot for the workaround, Shino!

Offline

#19 2025-10-04 15:22:11

seth
Member
From: Don't DM me only for attention
Registered: 2012-09-03
Posts: 68,992

Re: Rhythmbox crashing - Fatal glibc error

So either a bug in pixbuf2 or malloc - if you're indeed still getting this w/ gdk-pixbuf2 2.42.12 the bug seems to be glib2
https://gitlab.gnome.org/GNOME/glib/-/i … ge_size=20
Might be https://gitlab.gnome.org/GNOME/glib/-/issues/3695

Offline

#20 2025-10-04 17:47:09

IDKWhatToPutHere
Member
Registered: 2025-05-06
Posts: 12

Re: Rhythmbox crashing - Fatal glibc error

I downgraded glib2 to 2.84.4-2 as lotan suggested; it seems to work.

Last edited by IDKWhatToPutHere (2025-10-04 18:47:20)

Offline

#21 2025-10-04 19:56:10

Shino
Member
From: Germany
Registered: 2015-02-01
Posts: 106

Re: Rhythmbox crashing - Fatal glibc error

So I took the time to bisect glib

git bisect start
# status: waiting for both good and bad commits
# bad: [e33be08bda99f453e497064e9e021d6306bbeb7d] 2.86.0
git bisect bad e33be08bda99f453e497064e9e021d6306bbeb7d
# status: waiting for good commit(s), bad commit known
# good: [41eca60845d3fc309af361f5e7f801ba339099aa] 2.84.4
git bisect good 41eca60845d3fc309af361f5e7f801ba339099aa
# good: [eaa7e5bdfd2739a58d832362cb8dd1b11af29be0] 2.84.1
git bisect good eaa7e5bdfd2739a58d832362cb8dd1b11af29be0
# bad: [45869df93c153c920093de6e1ca4d66dd46db237] Merge branch 'regex-docs' into 'main'
git bisect bad 45869df93c153c920093de6e1ca4d66dd46db237
# bad: [a25e15695b73f3588ea3df109779c98d220cf65d] Merge branch 'wsign-conversion3' into 'main'
git bisect bad a25e15695b73f3588ea3df109779c98d220cf65d
# good: [976d01f81398fb7b4f26a8d8d3138679127db08d] Merge branch 'jsparber/allow_nested_handle' into 'main'
git bisect good 976d01f81398fb7b4f26a8d8d3138679127db08d
# good: [e237ec6c81fbb393c4a26b8ee14d4553ff65ee51] Merge branch 'get-binding-data-caller-allocates' into 'main'
git bisect good e237ec6c81fbb393c4a26b8ee14d4553ff65ee51
# bad: [4b7f0a8f50d52b695bba1c3f53fe8f54f8e5e7ff] gthread: Enable -Wsign-conversion for gthread subdirectory
git bisect bad 4b7f0a8f50d52b695bba1c3f53fe8f54f8e5e7ff
# bad: [752c0787d6176a339f6e1a9cdc0c17ce86dbb3f9] gparamspecs: Fix -Wsign-conversion warnings for large constants
git bisect bad 752c0787d6176a339f6e1a9cdc0c17ce86dbb3f9
# bad: [efed9028faf404b5c7752cfa1e9d4691a9f2b282] gobject: Fix various straightforward -Wsign-conversion warnings
git bisect bad efed9028faf404b5c7752cfa1e9d4691a9f2b282
# good: [3048266aa30a5bef8e2e89a312f441c189f47b4c] gstring: Add a new g_string_copy() method
git bisect good 3048266aa30a5bef8e2e89a312f441c189f47b4c
# bad: [b9d27192229fc9be3299a47f5ebd4a3163073a0c] gboxed: Use new g_string_copy() as boxed copy for GString
git bisect bad b9d27192229fc9be3299a47f5ebd4a3163073a0c
# first bad commit: [b9d27192229fc9be3299a47f5ebd4a3163073a0c] gboxed: Use new g_string_copy() as boxed copy for GString
commit b9d27192229fc9be3299a47f5ebd4a3163073a0c (HEAD)
Author: Philip Withnall <pwithnall@gnome.org>
Date:   Fri Apr 11 14:57:29 2025 +0100

    gboxed: Use new g_string_copy() as boxed copy for GString
    
    Rather than reinventing it ourselves. The old version in `gboxed.c`
    could lose the second half of very long strings, as it truncated the
    `size_t` string length to the `ssize_t` accepted by
    `g_string_new_len()`.
    
    Signed-off-by: Philip Withnall <pwithnall@gnome.org>
    
    Helps: #3405

 gobject/gboxed.c | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

https://gitlab.gnome.org/GNOME/glib/-/c … 3163073a0c

I don't get why that causes this bug... But maybe it's enough to report a bug somewhere.

EDIT: Opened an issue at GLib: https://gitlab.gnome.org/GNOME/glib/-/issues/3797

EDIT2: If I build  2.86.0-2 with the commit reverted

git revert b9d27192229fc9be3299a47f5ebd4a3163073a0c

the issue is indeed gone.

Last edited by Shino (2025-10-04 20:15:57)

Offline

#22 2025-10-04 20:42:33

IDKWhatToPutHere
Member
Registered: 2025-05-06
Posts: 12

Re: Rhythmbox crashing - Fatal glibc error

Good! I hope it's fixed.

Offline

#23 2025-10-04 21:37:01

lotan
Member
Registered: 2025-10-03
Posts: 8

Re: Rhythmbox crashing - Fatal glibc error

Shino wrote:

So I took the time to bisect glib

git bisect start
# status: waiting for both good and bad commits
# bad: [e33be08bda99f453e497064e9e021d6306bbeb7d] 2.86.0
git bisect bad e33be08bda99f453e497064e9e021d6306bbeb7d
# status: waiting for good commit(s), bad commit known
# good: [41eca60845d3fc309af361f5e7f801ba339099aa] 2.84.4
git bisect good 41eca60845d3fc309af361f5e7f801ba339099aa
# good: [eaa7e5bdfd2739a58d832362cb8dd1b11af29be0] 2.84.1
git bisect good eaa7e5bdfd2739a58d832362cb8dd1b11af29be0
# bad: [45869df93c153c920093de6e1ca4d66dd46db237] Merge branch 'regex-docs' into 'main'
git bisect bad 45869df93c153c920093de6e1ca4d66dd46db237
# bad: [a25e15695b73f3588ea3df109779c98d220cf65d] Merge branch 'wsign-conversion3' into 'main'
git bisect bad a25e15695b73f3588ea3df109779c98d220cf65d
# good: [976d01f81398fb7b4f26a8d8d3138679127db08d] Merge branch 'jsparber/allow_nested_handle' into 'main'
git bisect good 976d01f81398fb7b4f26a8d8d3138679127db08d
# good: [e237ec6c81fbb393c4a26b8ee14d4553ff65ee51] Merge branch 'get-binding-data-caller-allocates' into 'main'
git bisect good e237ec6c81fbb393c4a26b8ee14d4553ff65ee51
# bad: [4b7f0a8f50d52b695bba1c3f53fe8f54f8e5e7ff] gthread: Enable -Wsign-conversion for gthread subdirectory
git bisect bad 4b7f0a8f50d52b695bba1c3f53fe8f54f8e5e7ff
# bad: [752c0787d6176a339f6e1a9cdc0c17ce86dbb3f9] gparamspecs: Fix -Wsign-conversion warnings for large constants
git bisect bad 752c0787d6176a339f6e1a9cdc0c17ce86dbb3f9
# bad: [efed9028faf404b5c7752cfa1e9d4691a9f2b282] gobject: Fix various straightforward -Wsign-conversion warnings
git bisect bad efed9028faf404b5c7752cfa1e9d4691a9f2b282
# good: [3048266aa30a5bef8e2e89a312f441c189f47b4c] gstring: Add a new g_string_copy() method
git bisect good 3048266aa30a5bef8e2e89a312f441c189f47b4c
# bad: [b9d27192229fc9be3299a47f5ebd4a3163073a0c] gboxed: Use new g_string_copy() as boxed copy for GString
git bisect bad b9d27192229fc9be3299a47f5ebd4a3163073a0c
# first bad commit: [b9d27192229fc9be3299a47f5ebd4a3163073a0c] gboxed: Use new g_string_copy() as boxed copy for GString
commit b9d27192229fc9be3299a47f5ebd4a3163073a0c (HEAD)
Author: Philip Withnall <pwithnall@gnome.org>
Date:   Fri Apr 11 14:57:29 2025 +0100

    gboxed: Use new g_string_copy() as boxed copy for GString
    
    Rather than reinventing it ourselves. The old version in `gboxed.c`
    could lose the second half of very long strings, as it truncated the
    `size_t` string length to the `ssize_t` accepted by
    `g_string_new_len()`.
    
    Signed-off-by: Philip Withnall <pwithnall@gnome.org>
    
    Helps: #3405

 gobject/gboxed.c | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

https://gitlab.gnome.org/GNOME/glib/-/c … 3163073a0c

I don't get why that causes this bug... But maybe it's enough to report a bug somewhere.

EDIT: Opened an issue at GLib: https://gitlab.gnome.org/GNOME/glib/-/issues/3797

EDIT2: If I build  2.86.0-2 with the commit reverted

git revert b9d27192229fc9be3299a47f5ebd4a3163073a0c

the issue is indeed gone.

Shino, thank you very much for taking the time to bisect the issue.

Hopefully, one of the next releases contains a correction of this commit.

Offline

#24 2025-10-04 21:55:09

Shino
Member
From: Germany
Registered: 2015-02-01
Posts: 106

Re: Rhythmbox crashing - Fatal glibc error

lotan wrote:

Shino, thank you very much for taking the time to bisect the issue.

Hopefully, one of the next releases contains a correction of this commit.

You're welcome. However, I don't get why THAT is causing any problems. Maybe this just shifts some layout or whatever and the real bug is in another place. Let's see...

Offline

#25 2025-10-04 22:27:37

Shino
Member
From: Germany
Registered: 2015-02-01
Posts: 106

Re: Rhythmbox crashing - Fatal glibc error

As I thought, the issue is not GLib2.

They previously used the function g_string_new_len() to copy a string. This internally leads to a call of g_nearest_pow() to round the new allocated size to the next power of two.
Now they use g_string_copy() to copy strings, which copies the string exactly and does not allocate more memory than previously needed.

So there must be a buffer overflow somewhere else which was previously hidden due to the fact that GLib allocated more memory than strictly needed.

EDIT: I found the issue:


In rhythmbox's do_load_request function in rb-ext-db.c:

s = g_slice_new0 (GString);
		s->str = file_data;
		s->len = file_data_size;
		s->allocated_len = file_data_size;
		g_value_init (&d, G_TYPE_GSTRING);
		g_value_take_boxed (&d, s);

They generate a GString with len == allocated_len

However, g_string_copy (which is now used) looks like that:

GString *
g_string_copy (GString *string)
{
  GString *copy = NULL;

  g_return_val_if_fail (string != NULL, NULL);

  copy = g_slice_new (GString);
  copy->allocated_len = string->allocated_len + 0x1000;
  copy->len = string->len;

  /* We can’t just strdup(string->str) here because it may contain embedded nuls. */
  copy->str = g_malloc (copy->allocated_len);
  if (string->str != NULL && string->len > 0)
    memcpy (copy->str, string->str, string->len);
  copy->str[copy->len] = '\0';

  return g_steal_pointer (&copy);
}

See the

copy->str[copy->len] = '\0';

That's our out of bounds memory access that destroys everything.
I will report that to rhythmbox / Glib. Pretty sure this needs to be fixed in Glib and not in rhythmbox.

Last edited by Shino (2025-10-04 23:49:03)

Offline

Board footer

Powered by FluxBB