QL HEAD and 4.3.0 segfault when playing Internet Radio on Debian

[klausman]

Steps to reproduce

Installed QL 4.3.0 on Debian (or checked out current HEAD from Github), let QL populate the Internet Radio section, picked a random station, clicked play.

Expected Output

The picked station should play

Actual Output

QL exited with a a segfault:

src $ quodlibet/quodlibet.py 

** (io.github.quodlibet.QuodLibet:12816): WARNING **: 18:53:46.519: Binding 'XF86AudioRepeat' failed!

** (io.github.quodlibet.QuodLibet:12816): WARNING **: 18:53:46.520: Binding 'XF86AudioRandomPlay' failed!
Segmentation fault

Test System

Which version of Quod Libet?

4.3.0 or current HEAD

Which operating system

Debian Bullseye

If it's audio-related, what back-end?

gstreamer-1.18

Additional Information

This has been going on for months. I reported a bug with Debian, but 0 feedback:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970687

[dbeniamine]

Hi there,

First of all thanks for quodlibet, I think it's the best audio player on GNU Linux !

I am encountering this bug for month now, from what I understand it's a problem in libproxy1v5 which is called by gstreamer.

People using exaile encounter the exact same bug it seems to concern only people using quodlibet on Debian Xfce which is my case. People using Gnome seems not to see the bug because they use the GLibproxyResolver instead of directly using libproxy.

This is not a fix, do not do it for anything else than testing: I have tried, as suggested here to rename the libproxy.so file and indeed it fix the issue, but obviously it is a very bad idea.

I guess that someone should open an issue on libproxy but I am not sure what to put in the issue. It might be related to libpoxy isses 68 and 81.

Also I think it is link to this other debian bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971280

I'd love to help fixing this issue, what test can I do to help you ?

Just in case, there is the stack trace obtained running gdb --args /usr/bin/python3 /usr/bin/quodlibet --debug

Thread 10 "pool-io.github." received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffd9d3c700 (LWP 54533)]
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007ffff7c42537 in __GI_abort () at abort.c:79
#2  0x00007ffff5764301 in  () at /lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x00007ffff576f0cf in  () at /lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x00007ffff576f220 in __gxx_personality_v0 () at /lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x00007ffff2ed5e81 in __libunwind_Unwind_Resume () at /lib/x86_64-linux-gnu/libunwind.so.8
#6  0x00007fffda32f025 in  () at /lib/x86_64-linux-gnu/libproxy.so.1
#7  0x00007fffda32628c in  () at /lib/x86_64-linux-gnu/libproxy.so.1
#8  0x00007fffda3266a6 in  () at /lib/x86_64-linux-gnu/libproxy.so.1
#9  0x00007fffda326b21 in px_proxy_factory_get_proxies () at /lib/x86_64-linux-gnu/libproxy.so.1
#10 0x00007fffe99c955f in  () at /usr/lib/x86_64-linux-gnu/gio/modules/libgiolibproxy.so
#11 0x00007ffff6fef04e in  () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#12 0x00007ffff729b9a4 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x00007ffff729b0bd in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x00007ffff7f87ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#15 0x00007ffff7d1adef in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

[declension]

@dbeniamine Thanks for the investigation. I don't know what the next step is unfortunately (and don't see this myself), but reproducing in tests / Docker / CI would be one big step I guess...

[klausman]

@dbeniamine Thanks for the investigation. I don't know what the next step is unfortunately (and don't see this myself), but reproducing in tests / Docker / CI would be one big step I guess...

For me this has always been reproducible with a current testing Debian (bullseye), using no external packages, simple WM (i.e. no Gnome or other DE, just openbox), Quodlibet and no proxy vars set. Then with a clean user (i.e. no QL config), use the QL internal "Update streams list" function, and try to play any of the streams.

My best guess for Docker reproduction would be using the exact same binaries as Bullseye (not sure how much patching of libproxy Debian does). I don't think kernel version matters much. Not sure how I'd go about putting this into an integration test or CI env.

My "solution" to the problem was to rename the libproxy .so file to something ld would not find. Since I don't need the functionality (and QL happily runs without it), that was an option for me.

[dbeniamine]

My "solution" to the problem was to rename the libproxy .so file to something ld would not find. Since I don't need the functionality (and QL happily runs without it), that was an option for me.

From what I see, Network manager uses libproxy, as I use often a VPN this sounds like a bad idea for me.

reproducing in tests / Docker / CI would be one big step I guess...

Sounds like something I should be capable of doing, I'll give it a try !

Is there a way I can get a stack trace of QL calls ? I only managed to have a stack trace in the low level C code ...

Then I guess either find a work around in the way QL calls gstreamer, or report the issue to gstreamer or libproxy, I'm not sure which one is at fault here ...

[declension]

@dbeniamine not something I ever do, but have a look at the Useful development tools page for ideas

[dbeniamine]

So I have a branch with CI test running on a debian container, I currently have a few configuration bugs that I hope to fix quickly. Still our bug does not seems to be detected by the existing test. Could someone help me writing a test that plays an audio feed from internet ?

[jacekz2021]

The minimal working libproxy for QL I managed to write is the following:

#include <string.h>
#include <stdlib.h>
#include "proxy.h"

static char* t[2];

char **px_proxy_factory_get_proxies(pxProxyFactory *self, const char *url)
{
  char **_t;

  t[0]=strdup("direct://");
  t[1]=NULL;

  _t=malloc (sizeof (t));
  memcpy (_t, t, sizeof(t));

  return _t;
}

void px_proxy_factory_free_proxies(char **proxies)
{
}

void px_proxy_factory_free(pxProxyFactory *self)
{
}

Then:
gcc -c -Wall -Werror -fPIC pr.c
gcc -shared -o libpr.o pr.o
LD_PRELOAD=./libpr.o quodlibet

and it works! (Debian 11, xfce4)

Returning t instead of _t is not sufficient, as well as t[0]="direct://" - seems something is calling free() on them.

[dbeniamine]

I followed @jacekz2021 solution, to be a bit more explicit, I had to download proxy.h from here then building and launching quodlibet with the LD_PRELOAD fixes the issue.

I finally can listen my podcasts using quodlibet, thanks a lot !!

So now the question : have you shown this workaround to the libproxy devs so they can do an actual fix ?

[jacekz2021]

So now the question : have you shown this workaround to the libproxy devs so they can do an actual fix ?

No. I don't know where the problem really is. It can be QL as well as libproxy. As I wrote - it seams QL is calling free() on structures returned by libproxy and I don't know if is ok or not (and messing libproxy's memory management).