gmusicbrowser encounters errors after the latest Perl update to version 5.38

[noeltuote]

After updating Perl to version 5.38, gmusicbrowser has become unstable. Two main issues have been observed:

When using mpv as a backend, gmusicbrowser can only play one track before encountering a "connection refused" error related to the UNIX socket communication. This requires a manual restart of the mpv command with specific flags to rectify temporarily.

Errors related to GTK have been noticed, leading to occasional crashes and graphical glitches in the user interface.

These issues were not present prior to the Perl 5.38 update, indicating a potential incompatibility or unhandled behavior change in the newer version of Perl.

**failed to connect to socket (probably failed to launch mpv) Connection refused Commande utilisée : /usr/bin/mpv --input-unix-socket=/home/bureau/.config/gmusicbrowser/gmb_mpv_sock --idle --no-video --no-input-terminal --really-quiet --gapless-audio=weak --softvol-max=100 --mute=no --no-sub-auto --volume=100**

(gmusicbrowser:30963): Gtk-CRITICAL **: 16:26:37.291: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar

(gmusicbrowser:30963): Gtk-CRITICAL : 16:26:37.294: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar ** unhandled exception in callback: Illegal division by zero at /usr/bin/gmusicbrowser line 4270. *** ignoring at /usr/share/perl5/vendor_perl/Gtk3.pm line 572.

[squentin]

Sorry for not replying sooner. I used an archlinux installed on virtualbox, with everything updated, including perl v5.38.0, and tested with a bunch of mp3/ogg/opus/flac files, I can't find anything not working, tested with both gmb's git version and the outdated 1.1.99.1 release.

So, if you still have these problems, you need to give me more details, what distro, what version of gmb, mpv version, anything out of the ordinary...

[noeltuote]

Hello,

With the current configuration of my system, everything runs smoothly. Here's a brief summary of the software versions installed on my system:

mpv: 0.36.0, built on Sun Jul 23, 2023
curl: 8.2.1, released on 2023-07-26
GStreamer-related packages:
    gstreamer: 1.22.5-2
    phonon-qt5-gstreamer: 4.10.0-4

However, I've encountered issues after updating the following packages:

cairo-perl
glib-perl
pango-perl
perl
perl-cairo-gobject
perl-clone
perl-data-dump
perl-encode-locale
perl-error
perl-file-listing
perl-glib-object-introspection
perl-html-parser
perl-html-tagset
perl-http-cookies
perl-http-daemon
perl-http-date
perl-http-message
perl-http-negotiate
perl-image-exiftool
perl-io-html
perl-io-socket-ssl
perl-libwww
perl-locale-gettext
perl-log-message
perl-log-message-simple
perl-lwp-mediatypes
perl-lwp-protocol-https
perl-mailtools
perl-mozilla-ca
perl-net-dbus
perl-net-http
perl-net-ssleay
perl-term-readline-gnu
perl-term-ui
perl-text-iconv
perl-timedate
perl-try-tiny
perl-uri
perl-www-robotrules
perl-xml-parser
perl-xml-twig
perl-xml-writer

I suspect these updates may be causing the aforementioned issues. I would appreciate any guidance or suggestions you might have to resolve this. gmbrc.txt

[emiltoacs]

I have a similar issue after updating from Perl 5.36 to 5.38. When I start Gmusicbrowser, it quickly becomes totally irresponsive. To me, it seems to be an issue in between Perl and GTK. I have the same error as above in the log when I start gmusicbrowser -debug -noplugins

(gmusicbrowser:28404): Gtk-CRITICAL **: 08:59:02.837: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar

To reproduce the bug, one can start from an fresh gmbrc file, add a few albums in it's library, start playing songs, add some in queue. Close Gmusicbrowser. Restart Gmusicbrowser and now it's frozen. It seems that adding songs in queue makes Gmusicbrowser crashes faster. However even without that it eventually crashes after several restart.

With the latest version of Gmusicbrowser from git v1.1.99.1 commit 73089de

My system informations :

ArcoLinux (an Arch Linux flavor)
Linux x86_64 6.5.2-arch1-1
X.Org 21.1.8
Gnome 44.4
GTK 3.24.38
GTK 4.12.1
Gstreamer 1.22.5
Perl 5.38.0

Contrary to original post https://github.com/squentin/gmusicbrowser/issues/253#issue-1861650633 I'm using gstreamer not mpv

[noeltuote]

Hello, I really tried a lot of things, even starting with a new configuration it doesn't work. The application really seems not to work with perl updates after 5.38.0. It's really too bad, I love this app, if I could fix the problem I would, but I don't have the skills. All the other readers are so much worse...

[emiltoacs]

Hello, I really tried a lot of things, even starting with a new configuration it doesn't work.

At least gmusicbrowser should work for sometime once you start from a fresh ~/.config/gmusicbrowser/gmbrc then you add a few album and it looks ok. But latter (after a restart, or adding a lot of album to your library) gmusicbrowser seems to be stuck with one processor at 100% on usage. This may be related to this other issue https://github.com/squentin/gmusicbrowser/issues/254 mentioning memory leak, however even without any plugin I have the same bug.

The application really seems not to work with perl updates after 5.38.0.

Yes it is definitely some change between Perl 5.36 and 5.38 that made the bug appear.

It's really too bad, I love this app, if I could fix the problem I would, but I don't have the skills.

Same for me, I never used perl in my life and the only time I read perl was for this awesome gmusicbrowser player.

All the other readers are so much worse...

Yes that's surprising that in all these years none of the other music player had the capacity that gmusicbrowser have at least the basic possibilities of configuration to sort and display your music collection according to each tags as you like. I suppose that is because most of the users nowadays uses web services.

BTW if @squentin needs help for debugging I would be happy to provides any kind of experimentation and log to help.

[squentin]

I tried perl 5.38 both with a brand new arch install in a virtual machine and on my linux mint install with a manually compiled perl 5.38. I didn't find any problem, so I don't think it's coming from perl 5.38.

I can't fix it if I can't reproduce it.

If someone could reproduce this on a virtual machine and send me the (very big) image file (or step by step instructions to reproduce it on my end), I could investigate. Currently I do not know what I could do to try to reproduce it.

[emiltoacs]

Ok I'll try to figure out what's wrong aside perl 5.38 maybe the gtk version, I'll try that as soon as possible but now I'm in vacation.

[emiltoacs]

Following my investigations on GMusicBrowser freeze issue, the bug can be reproduced by starting from a brand new GMusicBrowser at commit 75c410d started with the following command to try to track the issue :

perl -w gmusicbrowser.pl -debug -backtrace -noplugins -cfg gmbrctest -nofifo &> logw10

Then adding a few directory with songs from your library then right-click on any song. @noeltuote can you help me to confirm that the bug comes from the interface ? When I start with a fresh gmusicbroswer as above, I have the freeze issue as soon as I right-click on some song in the interface.

I'm running an Arch Linux with : Kernel 6.7.1 GTK 3.24.41-1 Perl v5.38.2 GStreamer 1.22.9

I cannot find any relevant message in the log to help me track when and where this freeze happens.

[klauszeitler]

Looks just like the problem I had on openSUSE Tumbleweed. And I'm also pretty sure this is due to the switch to Perl 5.38. gmusicbrowser grabs 100% of the CPU as soon as I right click on anything. So finally I motivated myself into debugging gmusicbrowser, i.e. the tar ball 1.1.16 for GTK 2.

The culprit seems to be a redo-loop starting at line 4225 and ending at line 4243 in gmusicbrowser.pl. Changing line 4242 from: redo if grep $, @toobig; to: redo if $ && grep $_, @toobig; fixed the problem for me.

For the GTK 3 version, i.e. gmusicbrowser-1.1.99.1 the same applies to line 4370. But there are at least 2 more glitches with gmusicbrowser on openSUSE Tumbleweed. I hope I'll find some time in the next weeks to investigate these problems.

BTW using gmusicbrowser on openSUSE Tumbleweed proved to be quite cumbersome for quite a few months now. I haven't been able to update my system anymore cause this would break gmusicbrowser (there's no GTK 2 anymore and I ran into more problems when I tried to reinstall it) and the GTK 3 version doesn't work properly (as I stated above). So finally I removed gmusicbrowser with 'zypper rm', fetched the GTK 2 tar ball (1.1.16) locally, fixed gmusicbrowser.pl as shown above, and added Perl for GTK 2 via CPAN, i.e. with 'cpanm -f Gtk2'. Now I have a running gmusicbrowser again (for GTK 2 that is).

And many thanks to Quentin for the best music player I've seen so far!

[emiltoacs]

Thanks a lot @klauszeitler your fix also work for the latest commit 75c410d0dd71f116082aecd3b52af725f670521a

Changing line 4418 from redo if grep $, @toobig; to redo if $ && grep $_, @toobig;

fixes the right click freeze issue

thanks again to Quentin for this amazing music player

[squentin]

I'm not sure if the formatting ate some of the code, otherwise this code makes no sense. The line triggers a redo if one of the values in @toobig is true. I guess your change makes it never redo. This part of the code is responsible for building a alphabetical submenus if a menu is too big, so it's especially used for the list of artists when right clicking on current artist. Anyway, this bug seems different, if it's only caused by right clicking, can you check on what widget right clicking triggers the bug or not ?

[emiltoacs]

... otherwise this code makes no sense ... I guess your change makes it never redo.

Yes that proposition of klauszeitler is a workaround, not a real fix.

if it's only caused by right clicking, can you check on what widget right clicking triggers the bug or not ?

for me the bug happens for each right click, see my previous comment for a step by step reproducible experiment https://github.com/squentin/gmusicbrowser/issues/253#issuecomment-1912792111

[klauszeitler]

Yes, you're right, the web-based editor removed some underscores, it should have shown redo if $_ && grep $_, @toobig; I do remember, that $_ was always "" (i.e. empty string), but have to debug it again, cause I have forgotten what the contents of @toobig was. I'll see, if I find some time this weekend, to give you more information and a stack dump.

[emiltoacs]

In the grep context $_ is a special variable that takes consecutively the value of each element of the list @toobig, however outside of grep, I guess it should be undef.

FYI just commenting the line 4418 redo if grep $_, @toobig; is enough to make gmusicbrowser run without infinite loop freeze. The downside is that some menu cannot appear, such as the global search on the top right corner of the shimmer desktop.

[bor]

I guess I found the source of the issue. In short:

$ perl -E 'say(1080/34*0.8)'
25.4117647058824
$ perl -E 'use Gtk3 '-init'; say(1080/34*0.8)'
0

So due to this behavior we have 0 at line 4349

        $max= int($maxnb*.8)*($cols**.9);   # **.9 to reduce max height and optimum height when using columns

And then infinite loop with redo.

I don't know why that "calculation" happen and how to solve it correctly at the moment. But I suspect that may be a reason of other issues too. E.g. near with reviewed code we have glitches like

$ perl -E 'say 3**0.9'
2.68787537952229
$ perl -E 'use Gtk3 '-init'; say 3**0.9'
1

Hope that information will be usable to someone.

P.S. Thank you Quentin for the great player. P.P.S.

$ perl -E 'say $^V; use Gtk3; say Gtk3->VERSION;'
v5.38.2
0.038

[bor]

I did another quick research: In short: the issue is related to Gtk3 and locale, and here are possible workarounds

LANG= ./gmusicbrowser.pl
# or
LC_NUMERIC=C ./gmusicbrowser.pl

Explanation

It seems Perl 5.38 introduced some fixes for locale (1), but Gtk module has some workarounds that now do not work properly

$ env | grep '^LC\|^LANG'
LANG=uk_UA.UTF-8
LC_CTYPE=uk_UA.utf8
LC_COLLATE=C
$ perl -E 'use Gtk3 '-init'; say 1080/34;'
31,7647058823529
$ LC_NUMERIC=C perl -E 'use Gtk3 '-init'; say 1080/34;'
31.7647058823529

And it seems the story is not new in Perl history (2)(3). I'm not sure, but there is a commit related to this issue (4).

1. https://perldoc.perl.org/perl5380delta (grep locale)
2. https://github.com/perl/perl5/issues/13620
3. https://rt-archive.perl.org/perl5/Ticket/Display.html?id=121930
4. https://github.com/Perl/perl5/commit/996e6b9e17bebd710ff658cdb123da073ac0ee97

[bor]

I've placed the issue on the Gtk bug tracker and hope they know what to do.

https://gitlab.gnome.org/GNOME/perl-gtk3/-/issues/13

[squentin]

Thanks, there is indeed a problem with perl 5.38 when using non-english locales. As a workaround, it seems LC_NUMERIC=C might not be enough depending on your locales, using LC_ALL=C instead should work in all cases. I'll look into it and see what I can do.

[emiltoacs]

Wow thanks a lot changing the system locales made it.

For a quick fix, just change the Exec key in your /usr/share/applications/gmusicbrowser.desktop for

Exec=env LC_ALL=C gmusicbrowser %F

[noeltuote]

Well done and thank you! It works, the interface is no longer in French, but that doesn't matter because it works! Thank you so much

[squentin]

It seems that simply adding use locale qw/:numeric/; for example before this line in gmusicbrowser.pl use POSIX qw/setlocale LC_NUMERIC LC_MESSAGES LC_TIME strftime mktime getcwd _exit/; fixes it.

But I need to make more tests to make sure there isn't still some less noticeable locale bug that could affect values written in the save file or in tags. I've always been careful to only write values using LC_NUMERIC=C before, so that they are locale independent, so I need to make sure it's still the case, both in perl 5.38 and in previous ones.