Comment 1 Joe Marcus Clarke 2021-10-17 16:06:39 UTC

Pidgin works fine for me on 13-STABLE.  I do see the libjabber.so message, but this does not appear to be an issue (certainly not one causing the crash).  You'll need to follow the instructions on getting a core dump since I cannot reproduce.

pidgin.core
https://drive.google.com/file/d/1IBXDMlPmFpUP91ALC_N6HhuTtXz4aIbD/view?usp=sharing

Comment 3 Joe Marcus Clarke 2021-10-18 13:30:03 UTC

The core file does nothing for me.  This will be specific to your environment.  You need to use lldb on it to get a backtrace (see https://docs.freebsd.org/en/books/developers-handbook/tools/).  For example:

lldb -c pidgin.core -- /usr/local/bin/pidgin 
(lldb) thread backtrace all

(In reply to Joe Marcus Clarke from comment #3)
Oh sorry, I forgot about using lldb.
Here is the output:
* thread #1, name = 'pidgin', stop reason = signal SIGABRT
  * frame #0: 0x00000008019362ea libc.so.7`__sys_thr_kill + 10
    frame #1: 0x00000008018ab064 libc.so.7`__raise + 52
    frame #2: 0x000000080195ff29 libc.so.7`abort + 73
    frame #3: 0x00000000002b1fad pidgin`___lldb_unnamed_symbol712$$pidgin + 109
    frame #4: 0x0000000800eeee00 libthr.so.3`___lldb_unnamed_symbol124$$libthr.so.3 + 208
    frame #5: 0x0000000800eee3cf libthr.so.3`___lldb_unnamed_symbol105$$libthr.so.3 + 319
    frame #6: 0x00007ffffffff003
    frame #7: 0x0000000805f3a569 libpipewire-0.3.so.0`pw_split_walk + 41
    frame #8: 0x0000000805f1fc51 libpipewire-0.3.so.0`pw_load_spa_handle + 145
    frame #9: 0x0000000805f11147 libpipewire-0.3.so.0`pw_loop_new + 359
    frame #10: 0x0000000805f39610 libpipewire-0.3.so.0`___lldb_unnamed_symbol339$$libpipewire-0.3.so.0 + 96
    frame #11: 0x000000080572fe0f libgstpipewire.so`___lldb_unnamed_symbol113$$libgstpipewire.so + 143
    frame #12: 0x00000008005b3c6a libgstreamer-1.0.so.0`gst_device_provider_start + 138
    frame #13: 0x00000008005b2068 libgstreamer-1.0.so.0`gst_device_monitor_start + 536
    frame #14: 0x0000000801730409 libpurple.so.0`___lldb_unnamed_symbol212$$libpurple.so.0 + 1833
    frame #15: 0x00000008013bfd14 libgobject-2.0.so.0`g_type_create_instance + 532
    frame #16: 0x00000008013ad576 libgobject-2.0.so.0`___lldb_unnamed_symbol103$$libgobject-2.0.so.0 + 54
    frame #17: 0x00000008013accac libgobject-2.0.so.0`g_object_new + 252
    frame #18: 0x000000080173055b libpurple.so.0`purple_media_manager_get + 75
    frame #19: 0x00000008052b956d libjabber.so.0`jabber_plugin_init + 797
    frame #20: 0x000000080526e6a9 libxmpp.so`___lldb_unnamed_symbol1$$libxmpp.so + 9
    frame #21: 0x000000080173b19b libpurple.so.0`purple_plugin_load + 251
    frame #22: 0x000000080173c89f libpurple.so.0`purple_plugins_probe + 431
    frame #23: 0x0000000801716ea4 libpurple.so.0`purple_core_init + 324
    frame #24: 0x00000000002b1727 pidgin`main + 2055
    frame #25: 0x0000000000260870 pidgin`_start + 256
  thread #2, name = 'pool-spawner', stop reason = signal SIGABRT
    frame #0: 0x0000000800ee2b3c libthr.so.3`___lldb_unnamed_symbol1$$libthr.so.3 + 12
    frame #1: 0x0000000800ef2660 libthr.so.3`___lldb_unnamed_symbol186$$libthr.so.3 + 80
    frame #2: 0x0000000800ee469f libthr.so.3`___lldb_unnamed_symbol7$$libthr.so.3 + 623
    frame #3: 0x0000000801508835 libglib-2.0.so.0`g_cond_wait + 37
    frame #4: 0x000000080147d985 libglib-2.0.so.0`___lldb_unnamed_symbol17$$libglib-2.0.so.0 + 133
    frame #5: 0x00000008014de468 libglib-2.0.so.0`___lldb_unnamed_symbol242$$libglib-2.0.so.0 + 72
    frame #6: 0x00000008014dde42 libglib-2.0.so.0`___lldb_unnamed_symbol237$$libglib-2.0.so.0 + 66
    frame #7: 0x0000000800ee582b libthr.so.3`___lldb_unnamed_symbol11$$libthr.so.3 + 331

Comment 5 Joe Marcus Clarke 2021-10-18 14:03:12 UTC

The crash is happening in pipewire, not pidgin or libpurple.  Pipewire is a multimedia library.  You might try reinstalling that to see if it helps.  you might also try moving ~/.purple to ~/.purple.old to see if some setting is causing an interaction problem with pipewire (it's loading via the gstreamer system, so you might try reinstalling all of the core and good gstreamer plugins, too).

The pipewire maintainer, arrowd@FreeBSD.org might also be able to offer some suggestions, but you might need to rebuild pipewire with debugging symbols to get a better backtrace.

Comment 6 Gleb Popov 2021-10-22 12:45:48 UTC

How do you install packages? From an offical repository, build from source on the host, build from source with Poudriere?

(In reply to Gleb Popov from comment #6)
I install everything from the official repo. I tried to build Pidgin from the source disabling audio/video support and gstreammer. Unfortunately, got the same start failure.

Comment 8 Joe Marcus Clarke 2021-10-22 13:19:31 UTC

Looking at the pipewire code, it seems to me that the problem here might be that the sup->plugin_dir is NULL.  FreeBSD's strspn() doesn't like the string to be NULL.  Without full debugging symbols, it's hard to know, though...

Comment 9 Gleb Popov 2021-10-22 14:01:12 UTC

I also wasn't able to reproduce it on 14-CURRENT with packages build from source and 12.2-RELEASE with official binary packages.

Konstantin, you'll need to compile pipewire port with WITH_DEBUG=1 and then reproduce the backtrace.

(In reply to Gleb Popov from comment #9)
I created a VM with FreeBSD 13.0 and reproduced the issue. I installed Xorg, GNOME3, pidgin. Pidgin doesn't start on FreeBSD 13.0. I am sure this bug affects, at least, all GNOME users. I dunno if it is ok to debug in a virtual environment, as my office PC is not available until Monday.

I can confirm that after an update from 12.2-RELEASE-p3 to 13.0-RELEASE-p4 pidgin crash again (it happens to me on late August on a different machine, after another OS update), I solved removing gstreamer and re-build libpurple 2.14.4 from ports. Hope this help.

The only difference with default port option is:

OPTIONS_FILE_UNSET+=GSTREAMER

I also builded pipewire with -DWITH_DEBUG, reinstalled original pidgin and libpurple from official pkg to analyze backtrace but ...

(lldb) thread backtrace all
Program aborted due to an unhandled Error:
Error value was Success. (Note: Success values must still be checked prior to being destroyed).
PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace.
Stack dump:
0.      Program arguments: lldb -c pidgin.core -- /usr/local/bin/pidgin 
1.      HandleCommand(command = "thread backtrace all")
#0 0x0000000003ae7aee PrintStackTrace /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:564:13
#1 0x0000000003ae5fa5 RunSignalHandlers /usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:69:18
#2 0x0000000003ae8060 SignalHandler /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:0:3
#3 0x0000000804c35e00 handle_signal /usr/src/lib/libthr/thread/thr_sig.c:0:3
Abort (core dumped)

I got a 280MB core from lldb, doing lldb on that core I created a 1.7GB ones :-)

(In reply to Joe Marcus Clarke from comment #8)

Just to be sure I built using WITH_DEBUG=1 (instead of -DWITH_DEBUG) pipewire, libpurple and pidgin with standard options (gstreamer and all the stuff)

* thread #1, name = 'pidgin', stop reason = signal SIGABRT
  * frame #0: 0x00000008019a32ea libc.so.7`__sys_thr_kill + 10
    frame #1: 0x0000000801918064 libc.so.7`__raise + 52
    frame #2: 0x00000008019ccf29 libc.so.7`abort + 73
    frame #3: 0x00000000002dbb99 pidgin`sighandler(sig=11) at gtkmain.c:183:3
    frame #4: 0x0000000800f38e00 libthr.so.3`___lldb_unnamed_symbol124$$libthr.so.3 + 208
    frame #5: 0x0000000800f383cf libthr.so.3`___lldb_unnamed_symbol105$$libthr.so.3 + 319
    frame #6: 0x00007ffffffff003
    frame #7: 0x0000000806240fd8 libpipewire-0.3.so.0`open_plugin(registry=0x0000000000000000, path=0x0000000000000000, lib=0x0000000000000000) at pipewire.c:120:16
    frame #8: 0x0000000806240d58 libpipewire-0.3.so.0`pw_load_spa_handle(lib=0x0000000000000000, factory_name="", info=0x0000000000000000, n_support=0, support=0x00007fffffffd400) at pipewire.c:261:16
    frame #9: 0x00000008062282cf libpipewire-0.3.so.0`pw_loop_new(props=0x0000000000000000) at loop.c:79:24
    frame #10: 0x0000000806269a0c libpipewire-0.3.so.0`loop_new(loop=0x0000000000000000, name="", props=0x0000000000000000) at thread-loop.c:124:10
    frame #11: 0x0000000806269944 libpipewire-0.3.so.0`pw_thread_loop_new(name="", props=0x0000000000000000) at thread-loop.c:186:9
    frame #12: 0x00000008057309e1 libgstpipewire.so`gst_pipewire_device_provider_start(provider=0x0000000805eb5070) at gstpipewiredeviceprovider.c:595:22
    frame #13: 0x00000008005fcd1a libgstreamer-1.0.so.0`gst_device_provider_start + 138
    frame #14: 0x00000008005fb118 libgstreamer-1.0.so.0`gst_device_monitor_start + 536
    frame #15: 0x0000000801783913 libpurple.so.0`purple_media_manager_init_device_monitor(manager=0x000000080281f1a0) at mediamanager.c:2323:2
    frame #16: 0x000000080177ea53 libpurple.so.0`purple_media_manager_init(media=0x000000080281f1a0) at mediamanager.c:267:3
    frame #17: 0x00000008013ff8f4 libgobject-2.0.so.0`g_type_create_instance + 532
    frame #18: 0x00000008013ed1d6 libgobject-2.0.so.0`___lldb_unnamed_symbol102$$libgobject-2.0.so.0 + 54
    frame #19: 0x00000008013ec90c libgobject-2.0.so.0`g_object_new + 252
    frame #20: 0x000000080177eb69 libpurple.so.0`purple_media_manager_get at mediamanager.c:336:13
    frame #21: 0x00000008053c8b30 libjabber.so.0`jabber_do_init at jabber.c:3924:2
    frame #22: 0x00000008053c7f80 libjabber.so.0`jabber_plugin_init(plugin=0x000000080283f650) at jabber.c:3980:3
    frame #23: 0x00000008053737e5 libxmpp.so`load_plugin(plugin=0x000000080283f650) at libxmpp.c:142:2
    frame #24: 0x000000080178d5e0 libpurple.so.0`purple_plugin_load(plugin=0x000000080283f650) at plugin.c:590:38
    frame #25: 0x000000080178f63c libpurple.so.0`purple_plugins_probe(ext="") at plugin.c:1419:9
    frame #26: 0x000000080175a8ba libpurple.so.0`purple_core_init(ui="") at core.c:149:2
    frame #27: 0x00000000002db5f6 pidgin`main(argc=2, argv=0x00007fffffffe660) at gtkmain.c:826:7
    frame #28: 0x000000000025f0c0 pidgin`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1_c.c:75:7

  thread #2, name = 'pool-spawner', stop reason = signal SIGABRT
    frame #0: 0x0000000800f2cb3c libthr.so.3`___lldb_unnamed_symbol1$$libthr.so.3 + 12
    frame #1: 0x0000000800f3c660 libthr.so.3`___lldb_unnamed_symbol186$$libthr.so.3 + 80
    frame #2: 0x0000000800f2e69f libthr.so.3`___lldb_unnamed_symbol7$$libthr.so.3 + 623
    frame #3: 0x0000000801546345 libglib-2.0.so.0`g_cond_wait + 37
    frame #4: 0x00000008014bc055 libglib-2.0.so.0`___lldb_unnamed_symbol17$$libglib-2.0.so.0 + 133
    frame #5: 0x000000080151c018 libglib-2.0.so.0`___lldb_unnamed_symbol236$$libglib-2.0.so.0 + 72
    frame #6: 0x000000080151ba12 libglib-2.0.so.0`___lldb_unnamed_symbol231$$libglib-2.0.so.0 + 66
    frame #7: 0x0000000800f2f82b libthr.so.3`___lldb_unnamed_symbol11$$libthr.so.3 + 331

And here last used function from pipewire.c

    105 static struct plugin *
    106 open_plugin(struct registry *registry,
    107             const char *path, const char *lib)
    108 {
    109         struct plugin *plugin;
    110         char *filename;
    111         void *hnd;
    112         spa_handle_factory_enum_func_t enum_func;
    113         int res;
    114
    115         if ((filename = spa_aprintf("%s/%s.so", path, lib)) == NULL) {
    116                 res = -errno;
    117                 goto error_out;
    118         }
    119
    120         if ((plugin = find_plugin(registry, filename)) != NULL) {
    121                 free(filename);
    122                 plugin->ref++;
    123                 return plugin;
    124         }

(In reply to Riccardo Torrini from comment #11)
Thank you very much! That helped. Now I can use Pidgin on my PC.

Comment 15 Joe Marcus Clarke 2021-11-01 21:32:54 UTC

I still cannot reproduce running under GNOME.  I don't seem to be dlloading pipewire, though...

This new backtrace is interesting.  This is not where the initial reporter _seems_ to be crashing.  The code path looks as though something in the plugins under /usr/local/lib/spa-0.2 is tripping things up.  Can you provide the output of ls -lR of that directory?

Here's mine:

total 36
drwxr-xr-x  2 root  wheel  512 Sep 27 17:32 audioconvert/
drwxr-xr-x  2 root  wheel  512 Sep 27 17:32 audiomixer/
drwxr-xr-x  2 root  wheel  512 Sep 27 17:32 audiotestsrc/
drwxr-xr-x  2 root  wheel  512 Sep 27 17:32 control/
drwxr-xr-x  2 root  wheel  512 Sep 27 17:32 support/
drwxr-xr-x  2 root  wheel  512 Sep 27 17:32 v4l2/
drwxr-xr-x  2 root  wheel  512 Sep 27 17:32 videoconvert/
drwxr-xr-x  2 root  wheel  512 Sep 27 17:32 videotestsrc/
drwxr-xr-x  2 root  wheel  512 Sep 27 17:32 volume/

./audioconvert:
total 704
-rwxr-xr-x  1 root  wheel  678120 Sep 27 17:32 libspa-audioconvert.so*

./audiomixer:
total 88
-rwxr-xr-x  1 root  wheel  86936 Sep 27 17:32 libspa-audiomixer.so*

./audiotestsrc:
total 52
-rwxr-xr-x  1 root  wheel  50096 Sep 27 17:32 libspa-audiotestsrc.so*

./control:
total 40
-rwxr-xr-x  1 root  wheel  37160 Sep 27 17:32 libspa-control.so*

./support:
total 108
-rwxr-xr-x  1 root  wheel  16184 Sep 27 17:32 libspa-dbus.so*
-rwxr-xr-x  1 root  wheel  90536 Sep 27 17:32 libspa-support.so*

./v4l2:
total 88
-rwxr-xr-x  1 root  wheel  88408 Sep 27 17:32 libspa-v4l2.so*

./videoconvert:
total 88
-rwxr-xr-x  1 root  wheel  87672 Sep 27 17:32 libspa-videoconvert.so*

./videotestsrc:
total 48
-rwxr-xr-x  1 root  wheel  45624 Sep 27 17:32 libspa-videotestsrc.so*

./volume:
total 40
-rwxr-xr-x  1 root  wheel  39800 Sep 27 17:32 libspa-volume.so*

# cd /usr/local/lib/spa-0.2/ && ll -dnT "`find ./ -type f`"
-rwxr-xr-x  1 0  0  1442912 Oct 26 23:17:04 2021 ./alsa/libspa-alsa.so
-rwxr-xr-x  1 0  0  1473800 Oct 26 23:17:06 2021 ./audioconvert/libspa-audioconvert.so
-rwxr-xr-x  1 0  0   233544 Oct 26 23:17:06 2021 ./audiomixer/libspa-audiomixer.so
-rwxr-xr-x  1 0  0   131440 Oct 26 23:17:06 2021 ./audiotestsrc/libspa-audiotestsrc.so
-rwxr-xr-x  1 0  0   109368 Oct 26 23:17:06 2021 ./control/libspa-control.so
-rwxr-xr-x  1 0  0    46192 Oct 26 23:17:06 2021 ./support/libspa-dbus.so
-rwxr-xr-x  1 0  0   258168 Oct 26 23:17:06 2021 ./support/libspa-support.so
-rwxr-xr-x  1 0  0   253488 Oct 26 23:17:07 2021 ./v4l2/libspa-v4l2.so
-rwxr-xr-x  1 0  0   173864 Oct 26 23:17:06 2021 ./videoconvert/libspa-videoconvert.so
-rwxr-xr-x  1 0  0   131648 Oct 26 23:17:06 2021 ./videotestsrc/libspa-videotestsrc.so
-rwxr-xr-x  1 0  0   115664 Oct 26 23:17:06 2021 ./volume/libspa-volume.so

(my local build is not stripped, see comment #13, all dirs are 755, root:wheel, installed from ports because of debug)

# file alsa/libspa-alsa.so 
alsa/libspa-alsa.so: ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), dynamically linked, for FreeBSD 13.0 (1300139), with debug_info, not stripped

# pkg which /usr/local/lib/spa-0.2/alsa/libspa-alsa.so 
/usr/local/lib/spa-0.2/alsa/libspa-alsa.so was installed by package pipewire-0.3.31_4

# pkg info -l pipewire | grep lib/spa
        /usr/local/lib/spa-0.2/alsa/libspa-alsa.so
        /usr/local/lib/spa-0.2/audioconvert/libspa-audioconvert.so
        /usr/local/lib/spa-0.2/audiomixer/libspa-audiomixer.so
        /usr/local/lib/spa-0.2/audiotestsrc/libspa-audiotestsrc.so
        /usr/local/lib/spa-0.2/control/libspa-control.so
        /usr/local/lib/spa-0.2/support/libspa-dbus.so
        /usr/local/lib/spa-0.2/support/libspa-support.so
        /usr/local/lib/spa-0.2/v4l2/libspa-v4l2.so
        /usr/local/lib/spa-0.2/videoconvert/libspa-videoconvert.so
        /usr/local/lib/spa-0.2/videotestsrc/libspa-videotestsrc.so
        /usr/local/lib/spa-0.2/volume/libspa-volume.so

My installation include alsa but your not, maybe something about this?

Comment 17 Joe Marcus Clarke 2021-11-03 13:24:09 UTC

Certainly possible ALSA is the problem.  If you move that directory out of the way, does pidgin still crash?

Reinstalled libpurple and pidgin from official pkg

1. normal start -> crash
2. removed dir lib/spa-0.2/alsa (chmod 0 to be honest) -> crash
3. removed dir lib/spa-0.2 (same chmod 0) -> crash
4. truss pidgin | {some grep} ... last line is open("/usr/local/lib/libpipewire-0.3.so.0",O_RDONLY|O_CLOEXEC|O_VERIFY,00) = 10 (0xa)
5. chmod 0 /usr/local/lib/libpipewire-0.3.so.0.331.0 (the target of softlink)
6. normal start -> it works again

# ldd /usr/local/lib/libpipewire-0.3.so.0.331.0
/usr/local/lib/libpipewire-0.3.so.0.331.0:
        libdl.so.1 => /usr/lib/libdl.so.1 (0x80076c000)
        libintl.so.8 => /usr/local/lib/libintl.so.8 (0x800770000)
        libthr.so.3 => /lib/libthr.so.3 (0x80077f000)
        libc.so.7 => /lib/libc.so.7 (0x800263000)

In the meantime I have an update:
    pipewire: 0.3.31_4 -> 0.3.36_1

Can I proceed with the update? Do you prefer a local build with debug?

Comment 19 Gleb Popov 2021-11-04 08:10:22 UTC

I wonder if this bug is related to that one: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259621

I'll look into these in more detail after PipeWire 0.3.40 release.

A little update:
    pipewire: 0.3.31_4 -> 0.3.36_1
    libpurple: 2.14.4 -> 2.14.8
    pidgin: 2.14.4 -> 2.14.8

Same crash, same quick fix:
# chmod 0 /usr/local/lib/libpipewire-0.3.so.0.335.0

Just a note to my previous "quick fix".
Hiding libpipewire broke telegram-desktop :-(
(once started both programs work correctly)

FYI
2 x FreeBSD 13 machines built on same local poudriere repo with pidgin-2.14.4 installed, one pidgin worked, one broken with same stack trace in Comment 3. With the info supplied here I found that the broken machine had installed pipewire-0.3.36_1 as a requirement for something. I removed the pipewire package and required by dependencies and now both machine run pidgin fine.

Comment 23 commit-hook 2021-11-13 08:06:39 UTC

A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=36828f154cd27cae9f48f4d72da4cb30c9341c9f

commit 36828f154cd27cae9f48f4d72da4cb30c9341c9f
Author:     Gleb Popov <arrowd@FreeBSD.org>
AuthorDate: 2021-11-13 08:04:36 +0000
Commit:     Gleb Popov <arrowd@FreeBSD.org>
CommitDate: 2021-11-13 08:05:36 +0000

    multimedia/pipewire: Update to 0.3.40

    PR:             259166
    Reported by:    portscout!

 multimedia/pipewire/Makefile                       | 30 ++++++---
 multimedia/pipewire/distinfo                       |  8 ++-
 ...patch-spa_plugins_audioconvert_fmt-ops.h (gone) | 16 -----
 multimedia/pipewire/pkg-plist                      | 78 ++++++++++++++++++----
 4 files changed, 90 insertions(+), 42 deletions(-)

Comment 24 Gleb Popov 2021-11-13 08:07:35 UTC

OK, before I start digging this out, can someone please verify that the bug is still present with the newest PipeWire 0.3.40?

(In reply to Gleb Popov from comment #24)

No more crash !!

Only a new non-blocking message:

$ pidgin 
[E] pw.context [pipewire.c:256 load_spa_handle()] load lib: plugin directory undefined, set SPA_PLUGIN_DIR
[E] pw.loop [loop.c:86 pw_loop_new()] 0x805cf6f60: can't make support.system handle: No such file or directory

(telegram-desktop that depend from libpipewire still works)

FYI: I removed pipewire-336, telegram-desktop, libpurple and pidgin, installed pipewire-340 from ports, added telegram-desktop and pidgin from official pkg.

Nov 13 11:46:12 vixen pkg[93772]: telegram-desktop-3.1.9_1 deinstalled
Nov 13 11:46:12 vixen pkg[93772]: pipewire-0.3.36_1 deinstalled
Nov 13 11:46:21 vixen pkg[93791]: pipewire-0.3.40 installed
Nov 13 11:46:34 vixen pkg[93806]: pkg upgraded: 1.17.3 -> 1.17.4 
Nov 13 11:46:47 vixen pkg[93823]: telegram-desktop-3.1.9_1 installed
Nov 13 11:54:21 vixen pkg[93882]: pidgin-2.14.8 deinstalled
Nov 13 11:54:21 vixen pkg[93882]: libpurple-2.14.8 deinstalled
Nov 13 11:54:37 vixen pkg[93912]: libpurple-2.14.8 installed
Nov 13 11:54:38 vixen pkg[93912]: pidgin-2.14.8 installed

Comment 26 Gleb Popov 2021-11-13 11:36:11 UTC

(In reply to Riccardo Torrini from comment #25)
Did you disable that gstreamer workaround that was mentioned in this thread?

(In reply to Gleb Popov from comment #26)

I have gstreamer ON on pipewire-340 port, all others installed from pkg.
Disabling gstreamer was my first workaround, last quick one was chmod 0 on libpipewire before starting pidgin (and chmod 755 before launching telegram)

Comment 28 Gleb Popov 2021-11-14 08:09:55 UTC

Great, closing the PR, then.