Bug 259621 - multimedia/pipewire: SIGSEGV due to ambiguous pw_init
Summary: multimedia/pipewire: SIGSEGV due to ambiguous pw_init
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Some People
Assignee: Gleb Popov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-11-02 18:44 UTC by Alex Protasenko
Modified: 2021-11-21 13:41 UTC (History)
2 users (show)

See Also:
arrowd: maintainer-feedback+
jbeich: merge-quarterly+


Attachments
Patch (1.24 KB, patch)
2021-11-17 10:20 UTC, Gleb Popov
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Protasenko 2021-11-02 18:44:08 UTC
Segfaults on startup in various Gnome3 programs, e.g. cheese, some areas of gnome-control-center (e.g. Users).
The problem stems from pw_init() ambiguously exported from both libpipewire.so and libutil.so.
The libgstpipewire.so's plugin_init() calls pw_init() to initialize libpipewire. Since libgstpipewire.so links to both libpipewire.so and libutil.so, on my system it happens to call pw_init exported from libutil.so instead of the libpipewire.so's one. Both exports take two pointers as parameters and the SIGSEGV occurs later on when effectively uninitialized libpipewire starts being used.

The backtrace when SIGSEGV actually occurs looks like:

Thread 1 received signal SIGSEGV, Segmentation fault.
Address not mapped to object.
0x0000000801477aa6 in strspn () from /lib/libc.so.7
(gdb) bt
#0  0x0000000801477aa6 in strspn () at /lib/libc.so.7
#1  0x000000081a612569 in pw_split_walk () at /usr/local/lib/libpipewire-0.3.so.0
#2  0x000000081a5f7c51 in pw_load_spa_handle () at /usr/local/lib/libpipewire-0.3.so.0
#3  0x000000081a5e9147 in pw_loop_new () at /usr/local/lib/libpipewire-0.3.so.0
...
Comment 1 Gleb Popov freebsd_committer 2021-11-13 08:29:16 UTC
The problem is understood, but I have no idea how to fix this properly.
Comment 2 Konstantin Belousov freebsd_committer 2021-11-16 10:18:55 UTC
Why does libgstpipewire.so needs to link to libutil.so, which services it require
from the library?

If libutil.so is indeed required, I suspect there is no way around other than:
- either ensure that -lpipewire is specified before -lutil
- or rename pw_util symbol into something else with #define for libpipewire
  and its consumers.  This would be a local patch that we have to keep forever.

There might be yet another solution, but it is relatively complicated.  pipewire
port might provide so called filter library over libutil.so, which re-export
everything except conflicting symbols.  Then link against this filter and not
the genuine libutil.so.
Comment 3 Alex Protasenko 2021-11-16 16:13:43 UTC
libpipewire itself doesn't have libutil dependency.
In case of `cheese` program, it's /usr/local/lib/libgstreamer-1.0.so.0 which does:
/usr/local/lib/libgstreamer-1.0.so.0:
        libgobject-2.0.so.0 => /usr/local/lib/libgobject-2.0.so.0 (0x801000000)
        libgmodule-2.0.so.0 => /usr/local/lib/libgmodule-2.0.so.0 (0x8007be000)
        libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x801059000)
        libintl.so.8 => /usr/local/lib/libintl.so.8 (0x8007c4000)
        libunwind.so.8 => /usr/local/lib/libunwind.so.8 (0x8007d3000)
        libm.so.5 => /lib/libm.so.5 (0x801194000)
        librt.so.1 => /usr/lib/librt.so.1 (0x8007ed000)
        libdl.so.1 => /usr/lib/libdl.so.1 (0x8007f6000)
        libthr.so.3 => /lib/libthr.so.3 (0x8011c7000)
        libc.so.7 => /lib/libc.so.7 (0x800263000)
        libffi.so.7 => /usr/local/lib/libffi.so.7 (0x8011f4000)
        libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x8011ff000)
        libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x8012a3000)
        libutil.so.9 => /lib/libutil.so.9 (0x8013a2000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x8013ba000)
        liblzma.so.5 => /usr/lib/liblzma.so.5 (0x8013d3000)
        libz.so.6 => /lib/libz.so.6 (0x8013ff000)
        libmd.so.6 => /lib/libmd.so.6 (0x80141b000)

Specifying right lib search order -la -lb etc would probably solve the issue, but libpipewire is not linked to libgstreamer at compile time, it's probably dlopen'ed by libgstpipewire plugin at runtime. Eliminating libutil from gstreamer's dependencies might be the way to go. Here's full backtrace of `cheese` at time of SEGV. Note, the pw_init was already called at this point:

(gdb) bt
#0  0x0000000801477aa6 in strspn () at /lib/libc.so.7
#1  0x000000084acb9569 in pw_split_walk () at /usr/local/lib/libpipewire-0.3.so.0
#2  0x000000084ac9ec51 in pw_load_spa_handle () at /usr/local/lib/libpipewire-0.3.so.0
#3  0x000000084ac90147 in pw_loop_new () at /usr/local/lib/libpipewire-0.3.so.0
#4  0x000000084acb8610 in  () at /usr/local/lib/libpipewire-0.3.so.0
#5  0x000000084ac19e0f in  () at /usr/local/lib/gstreamer-1.0/libgstpipewire.so
#6  0x000000080120dd1a in gst_device_provider_start () at /usr/local/lib/libgstreamer-1.0.so.0
#7  0x000000080120c118 in gst_device_monitor_start () at /usr/local/lib/libgstreamer-1.0.so.0
#8  0x00000008002a18e0 in  () at /usr/local/lib/libcheese.so.8
#9  0x0000000800d806e7 in g_initable_new_valist () at /usr/local/lib/libgio-2.0.so.0
#10 0x0000000800d805fe in g_initable_new () at /usr/local/lib/libgio-2.0.so.0
#11 0x000000080029d5aa in cheese_camera_setup () at /usr/local/lib/libcheese.so.8
#12 0x000000000022fb98 in  ()
#13 0x000000000023138e in  ()
#14 0x0000000800e8c3cd in  () at /usr/local/lib/libgobject-2.0.so.0
#15 0x0000000800ea2596 in g_signal_emit_valist () at /usr/local/lib/libgobject-2.0.so.0
#16 0x0000000800ea2ff6 in g_signal_emit () at /usr/local/lib/libgobject-2.0.so.0
#17 0x00000000002302ad in  ()
#18 0x0000000800d87ca6 in  () at /usr/local/lib/libgio-2.0.so.0
#19 0x0000000800e8c3cd in  () at /usr/local/lib/libgobject-2.0.so.0
#20 0x0000000800ea2596 in g_signal_emit_valist () at /usr/local/lib/libgobject-2.0.so.0
#21 0x0000000800ea2ff6 in g_signal_emit () at /usr/local/lib/libgobject-2.0.so.0
#22 0x0000000800de3f74 in  () at /usr/local/lib/libgio-2.0.so.0
#23 0x0000000800de5d6f in  () at /usr/local/lib/libgio-2.0.so.0
#24 0x0000000800de3cea in g_application_run () at /usr/local/lib/libgio-2.0.so.0
#25 0x000000000023246e in  ()
#26 0x000000000022f640 in  ()
#27 0x000000000022f540 in  ()
#28 0x0000000000000000 in  ()
Comment 4 Alex Protasenko 2021-11-16 16:21:41 UTC
Btw, even if libgstreamer no longer depends on libutil, there are others like `gnome-control-center` program, which depend on
/usr/local/lib/libgstreamer-1.0.so.0
/usr/lib/libprocstat.so.1
/usr/local/lib/libsecret-1.so.0

And each of those individually depend on libutil, or at least specify -lutil at compile time...
Comment 5 Gleb Popov freebsd_committer 2021-11-17 10:20:55 UTC
Created attachment 229547 [details]
Patch

Upstream provided following patch. Drop it into `multimedia/pipewire/files` directory, rebuild the port and check if it fixes the issue.
Comment 6 Alex Protasenko 2021-11-17 13:52:47 UTC
Yes, this fixed the issue! `cheese` now works fine in gnome-shell environment. Also the 'Users' and other sections of gnome-control-center now work too, except I still have an issue with 'Power' section, but that was there before and looks like configuration issue (possibly related to schema 'org.gnome.settings-daemon.plugins.power' does not contain a key named 'power-saver-profile-on-low-battery').

Thanks!
Comment 7 commit-hook freebsd_committer 2021-11-20 16:50:46 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=8691df3a5142ab9381d6f1c9af2377dd4696e084

commit 8691df3a5142ab9381d6f1c9af2377dd4696e084
Author:     Gleb Popov <arrowd@FreeBSD.org>
AuthorDate: 2021-11-20 16:47:48 +0000
Commit:     Gleb Popov <arrowd@FreeBSD.org>
CommitDate: 2021-11-20 16:49:30 +0000

    multimedia/pipewire: Add a patch to fix ambguous function name issue.

    PR:             259621

 multimedia/pipewire/Makefile                       |  1 +
 .../files/patch-src_pipewire_pipewire_init (new)   | 67 ++++++++++++++++++++++
 2 files changed, 68 insertions(+)
Comment 8 commit-hook freebsd_committer 2021-11-20 22:42:54 UTC
A commit in branch main references this bug:

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

commit e92349ca0c3d9b0ccdb1e5d40b3b536b39f56890
Author:     Jan Beich <jbeich@FreeBSD.org>
AuthorDate: 2021-11-20 22:05:10 +0000
Commit:     Jan Beich <jbeich@FreeBSD.org>
CommitDate: 2021-11-20 22:41:23 +0000

    multimedia/pipewire: force rebuild consumers after 8691df3a5142

    ABI has changed: pw_{,de}init -> pipewire_{,de}init. As PipeWire
    support is often runtime-optional the breakage maybe hard to notice.

     ERROR kooha::backend::screencast_portal > Error from screencast call: Zbus(MethodError(OwnedInterfaceName(InterfaceName(Str("org.freedesktop.DBus.Error.UnknownMethod"))), Some("No such interface “org.freedesktop.portal.ScreenCast” on object at path /org/freedesktop/portal/desktop"), Msg { type: Error, sender: UniqueName(Str(":1.397")), reply-serial: 18, body: Signature: [
            s (115),
    ] }))

    ld-elf.so.1: /usr/local/libexec/xdg-desktop-portal-wlr: Undefined symbol "pw_init"

    PR:             259621

 audio/musicpd/Makefile                | 1 +
 deskutils/xdg-desktop-portal/Makefile | 2 +-
 net-im/telegram-desktop/Makefile      | 1 +
 net-im/tg_owt/Makefile                | 2 +-
 x11-wm/gamescope/Makefile             | 1 +
 x11-wm/mutter/Makefile                | 1 +
 x11/xdg-desktop-portal-wlr/Makefile   | 1 +
 7 files changed, 7 insertions(+), 2 deletions(-)
Comment 9 commit-hook freebsd_committer 2021-11-20 22:51:59 UTC
A commit in branch 2021Q4 references this bug:

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

commit add690556ebdda0de00204c24f0de911de82b1dd
Author:     Jan Beich <jbeich@FreeBSD.org>
AuthorDate: 2021-11-20 22:05:10 +0000
Commit:     Jan Beich <jbeich@FreeBSD.org>
CommitDate: 2021-11-20 22:43:42 +0000

    multimedia/pipewire: force rebuild consumers after 8691df3a5142

    ABI has changed: pw_{,de}init -> pipewire_{,de}init. As PipeWire
    support is often runtime-optional the breakage maybe hard to notice.

     ERROR kooha::backend::screencast_portal > Error from screencast call: Zbus(MethodError(OwnedInterfaceName(InterfaceName(Str("org.freedesktop.DBus.Error.UnknownMethod"))), Some("No such interface “org.freedesktop.portal.ScreenCast” on object at path /org/freedesktop/portal/desktop"), Msg { type: Error, sender: UniqueName(Str(":1.397")), reply-serial: 18, body: Signature: [
            s (115),
    ] }))

    ld-elf.so.1: /usr/local/libexec/xdg-desktop-portal-wlr: Undefined symbol "pw_init"

    PR:             259621
    (cherry picked from commit e92349ca0c3d9b0ccdb1e5d40b3b536b39f56890)

 deskutils/xdg-desktop-portal/Makefile | 2 +-
 net-im/telegram-desktop/Makefile      | 2 +-
 net-im/tg_owt/Makefile                | 2 +-
 x11-wm/gamescope/Makefile             | 1 +
 x11-wm/mutter/Makefile                | 1 +
 x11/xdg-desktop-portal-wlr/Makefile   | 2 +-
 6 files changed, 6 insertions(+), 4 deletions(-)
Comment 10 commit-hook freebsd_committer 2021-11-20 22:52:00 UTC
A commit in branch 2021Q4 references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=031836e2ec8b0463dec91f282f9cdfde38281008

commit 031836e2ec8b0463dec91f282f9cdfde38281008
Author:     Gleb Popov <arrowd@FreeBSD.org>
AuthorDate: 2021-11-20 16:47:48 +0000
Commit:     Jan Beich <jbeich@FreeBSD.org>
CommitDate: 2021-11-20 21:31:15 +0000

    multimedia/pipewire: Add a patch to fix ambguous function name issue.

    PR:             259621
    (cherry picked from commit 8691df3a5142ab9381d6f1c9af2377dd4696e084)

 multimedia/pipewire/Makefile                       |  2 +-
 .../files/patch-src_pipewire_pipewire_init (new)   | 67 ++++++++++++++++++++++
 2 files changed, 68 insertions(+), 1 deletion(-)
Comment 11 Jan Beich freebsd_committer 2021-11-20 22:53:23 UTC
Backported to /quarterly because this also fixed multimedia/kooha crash after pressing Record button. Kooha itself links against libutil and libutil is linked via some of Kooha dependencies (gstreamer1, gstreamer1-plugins, gtk4, graphene, libadwaita, pango, harfbuzz, gdk-pixbuf2).

* thread #1, name = 'kooha', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
    frame #0: 0x000031afd911e52b libc.so.7`strspn(s=0x0000000000000000, charset=":") at strspn.c:51:5
   48           u_long tbl[(UCHAR_MAX + 1) / LONG_BIT];
   49           int idx;
   50
-> 51           if(*s == '\0')
   52                   return (0);
   53
   54   #if LONG_BIT == 64      /* always better to unroll on 64-bit architectures */
(lldb) bt
* thread #1, name = 'kooha', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
  * frame #0: 0x000031afd911e52b libc.so.7`strspn(s=0x0000000000000000, charset=":") at strspn.c:51:5
    frame #1: 0x000031b05b93b923 libpipewire-0.3.so.0`pw_split_walk(str=0x0000000000000000, delimiter=":", len=0x00007fffffcc9978, state=0x00007fffffcc9980) at utils.c:47:7
    frame #2: 0x000031b05b91316c libpipewire-0.3.so.0`pw_load_spa_handle(lib=0x0000000000000000, factory_name="support.system", info=0x0000000000000000, n_support=0, support=0x00007fffffcc9a70) at pipewire.c:273:14
    frame #3: 0x000031b05b8fba4f libpipewire-0.3.so.0`pw_loop_new(props=0x0000000000000000) at loop.c:79:24
    frame #4: 0x000031b05b939fa8 libpipewire-0.3.so.0`loop_new(loop=0x0000000000000000, name="pipewire-main-loop", props=0x0000000000000000) at thread-loop.c:124:10
    frame #5: 0x000031b05b939ee1 libpipewire-0.3.so.0`pw_thread_loop_new(name="pipewire-main-loop", props=0x0000000000000000) at thread-loop.c:186:9
    frame #6: 0x000031b05cceb8d2 libgstpipewire.so`make_core(fd=19) at gstpipewirecore.c:73:16
    frame #7: 0x000031b05cceb71e libgstpipewire.so`gst_pipewire_core_get(fd=19) at gstpipewirecore.c:147:12
    frame #8: 0x000031b05ccf8eea libgstpipewire.so`gst_pipewire_src_open(pwsrc=0x000031b04bfb18e0) at gstpipewiresrc.c:1112:17
    frame #9: 0x000031b05ccf71e9 libgstpipewire.so`gst_pipewire_src_change_state(element=0x000031b04bfb18e0, transition=GST_STATE_CHANGE_NULL_TO_READY) at gstpipewiresrc.c:1216:12
    frame #10: 0x000031afd3ac4743 libgstreamer-1.0.so.0`gst_element_change_state(element=0x000031b04bfb18e0, transition=GST_STATE_CHANGE_NULL_TO_READY) at gstelement.c:2952:11
    frame #11: 0x000031afd3ac7015 libgstreamer-1.0.so.0`gst_element_set_state_func(element=0x000031b04bfb18e0, state=GST_STATE_READY) at gstelement.c:2906:9
    frame #12: 0x000031afd3ac3dc2 libgstreamer-1.0.so.0`gst_element_set_state(element=0x000031b04bfb18e0, state=GST_STATE_READY) at gstelement.c:2807:14
    frame #13: 0x000031afd3a8d819 libgstreamer-1.0.so.0`gst_bin_element_set_state(bin=0x000031b04c0321e0, element=0x000031b04bfb18e0, base_time=0, start_time=0, current=GST_STATE_NULL, next=GST_STATE_READY) at gstbin.c:2605:9
    frame #14: 0x000031afd3a87722 libgstreamer-1.0.so.0`gst_bin_change_state_func(element=0x000031b04c0321e0, transition=GST_STATE_CHANGE_NULL_TO_READY) at gstbin.c:2947:15
    frame #15: 0x000031afd3b04687 libgstreamer-1.0.so.0`gst_pipeline_change_state(element=0x000031b04c0321e0, transition=GST_STATE_CHANGE_NULL_TO_READY) at gstpipeline.c:504:12
    frame #16: 0x000031afd3ac4743 libgstreamer-1.0.so.0`gst_element_change_state(element=0x000031b04c0321e0, transition=GST_STATE_CHANGE_NULL_TO_READY) at gstelement.c:2952:11
    frame #17: 0x000031afd3ac7015 libgstreamer-1.0.so.0`gst_element_set_state_func(element=0x000031b04c0321e0, state=GST_STATE_PLAYING) at gstelement.c:2906:9
    frame #18: 0x000031afd3ac3dc2 libgstreamer-1.0.so.0`gst_element_set_state(element=0x000031b04c0321e0, state=GST_STATE_PLAYING) at gstelement.c:2807:14
    frame #19: 0x000031a7d072d525 kooha`_$LT$kooha..backend..recorder..imp..Recorder$u20$as$u20$glib..subclass..object..ObjectImpl$GT$::set_property::h0b4cccf7efe128ca + 325
    frame #20: 0x000031a7d073a583 kooha`glib::subclass::object::set_property::hce3789fc1cf614d5 + 83
    frame #21: 0x000031afd1c70968 libgobject-2.0.so.0`object_set_property(object=0x000031b00916f390, pspec=0x000031b002c04130, value=0x00007fffffccab28, nqueue=0x000031b0091bf080) at gobject.c:1571:7
    frame #22: 0x000031afd1c70441 libgobject-2.0.so.0`g_object_setv(object=0x000031b00916f390, n_properties=1, names=0x00007fffffccaab0, values=0x00007fffffccab28) at gobject.c:2410:7
    frame #23: 0x000031afd1c71af8 libgobject-2.0.so.0`g_object_set_property(object=0x000031b00916f390, property_name="state", value=0x00007fffffccab28) at gobject.c:2698:3
    frame #24: 0x000031a7d06ed424 kooha`kooha::backend::recorder::Recorder::set_state::h137c331c577ded7b + 324
    frame #25: 0x000031a7d06ef4c0 kooha`kooha::backend::recorder::Recorder::start::h3c61ef928fec92fd + 256
    frame #26: 0x000031a7d06e305e kooha`_$LT$T$u20$as$u20$glib..object..ObjectExt$GT$::connect_local::_$u7b$$u7b$closure$u7d$$u7d$::hc10a5da41e6a503a + 110
    frame #27: 0x000031a7d06e61cd kooha`glib::closure::Closure::new_unsafe::marshal::h2ccecf936b317c6a (.llvm.4490151282539723725) + 29
    frame #28: 0x000031afd1c64ed5 libgobject-2.0.so.0`g_closure_invoke(closure=0x000031b002d802a0, return_value=0x0000000000000000, n_param_values=1, param_values=0x00007fffffccb2d0, invocation_hint=0x00007fffffccb0d8) at gclosure.c:830:7
    frame #29: 0x000031afd1c8660b libgobject-2.0.so.0`signal_emit_unlocked_R(node=0x000031b006ba87a0, detail=0, instance=0x000031b009170d60, emission_return=0x0000000000000000, instance_and_params=0x00007fffffccb2d0) at gsignal.c:3742:8
    frame #30: 0x000031afd1c85e23 libgobject-2.0.so.0`g_signal_emitv(instance_and_params=0x00007fffffccb2d0, signal_id=108, detail=0, return_value=0x0000000000000000) at gsignal.c:3227:3
    frame #31: 0x000031a7d06a86eb kooha`_$LT$T$u20$as$u20$glib..object..ObjectExt$GT$::emit_by_name::h365c55bac4488a61 + 843
    frame #32: 0x000031a7d06b29f8 kooha`kooha::backend::timer::Timer::start::h1d03a2d580432504 + 248
    frame #33: 0x000031a7d06e2adc kooha`_$LT$T$u20$as$u20$glib..object..ObjectExt$GT$::connect_local::_$u7b$$u7b$closure$u7d$$u7d$::h64cd76f875e384b4 + 124
    frame #34: 0x000031a7d06e65bd kooha`glib::closure::Closure::new_unsafe::marshal::h4fa0bed22a871b6a (.llvm.4490151282539723725) + 29
    frame #35: 0x000031afd1c64ed5 libgobject-2.0.so.0`g_closure_invoke(closure=0x000031b002d6ffe0, return_value=0x0000000000000000, n_param_values=1, param_values=0x00007fffffccbb20, invocation_hint=0x00007fffffccb928) at gclosure.c:830:7
    frame #36: 0x000031afd1c8660b libgobject-2.0.so.0`signal_emit_unlocked_R(node=0x000031b006ba8b60, detail=0, instance=0x000031b00916f390, emission_return=0x0000000000000000, instance_and_params=0x00007fffffccbb20) at gsignal.c:3742:8
    frame #37: 0x000031afd1c85e23 libgobject-2.0.so.0`g_signal_emitv(instance_and_params=0x00007fffffccbb20, signal_id=106, detail=0, return_value=0x0000000000000000) at gsignal.c:3227:3
    frame #38: 0x000031a7d06e9748 kooha`_$LT$T$u20$as$u20$glib..object..ObjectExt$GT$::emit_by_name::hf22667b62549d04f (.llvm.3901114416550982646) + 856
    frame #39: 0x000031a7d06ed92a kooha`kooha::backend::recorder::Recorder::build_pipeline::hef9f114f35e10421 + 666
    frame #40: 0x000031a7d06ceec6 kooha`_$LT$core..future..from_generator..GenFuture$LT$T$GT$$u20$as$u20$core..future..future..Future$GT$::poll::hdc0f29e8cfbe351f + 6902
    frame #41: 0x000031a7d08acf99 kooha`glib::main_context::_$LT$impl$u20$glib..auto..main_context..MainContext$GT$::with_thread_default::haf36bc4ef3fd9e2a + 137
    frame #42: 0x000031a7d08a7d6a kooha`glib::main_context_futures::TaskSource::dispatch::h626774632a35a388 (.llvm.1230265796533566852) + 58
    frame #43: 0x000031afd2a2a825 libglib-2.0.so.0`g_main_dispatch(context=0x000031b002c206c0) at gmain.c:3381:27
    frame #44: 0x000031afd2a2a660 libglib-2.0.so.0`g_main_context_dispatch(context=0x000031b002c206c0) at gmain.c:4099:7
    frame #45: 0x000031afd2a2abb0 libglib-2.0.so.0`g_main_context_iterate(context=0x000031b002c206c0, block=1, dispatch=1, self=0x000031b002c47a40) at gmain.c:4175:5
    frame #46: 0x000031afd2a2ac53 libglib-2.0.so.0`g_main_context_iteration(context=0x000031b002c206c0, may_block=1) at gmain.c:4240:12
    frame #47: 0x000031afd6ee720d libgio-2.0.so.0`g_application_run(application=0x000031b006bd9150, argc=1, argv=0x000031b002d7e040) at gapplication.c:2569:7
    frame #48: 0x000031a7d06e8fb1 kooha`kooha::application::Application::run::hb55283e0eed45f72 + 769
    frame #49: 0x000031a7d06dedbd kooha`kooha::main::hf8757a3b2068848d + 381
    frame #50: 0x000031a7d07377f3 kooha`std::sys_common::backtrace::__rust_begin_short_backtrace::h3eb75b04487bf6a3 + 3
    frame #51: 0x000031a7d0725249 kooha`std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::h5c5a57569b040be7 (.llvm.17216673041266972443) + 9
    frame #52: 0x000031a7d08c4981 kooha`std::rt::lang_start_internal::hed5448c7acecc2aa + 33
    frame #53: 0x000031a7d06deff2 kooha`main + 34
    frame #54: 0x000031a7d066c146 kooha`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1_c.c:73:7
Comment 12 Jan Beich freebsd_committer 2021-11-20 23:05:57 UTC
(In reply to Jan Beich from comment #11)
> Kooha itself links against libutil and libutil is linked via some of Kooha dependencies...

Err, libutil is pulled via libglib-2.0 (from devel/glib20) which Kooha directly depends on and pulls via other dependencies.
Comment 13 Konstantin Belousov freebsd_committer 2021-11-20 23:48:22 UTC
IMO, somebody (upstream?) should bump dso version.
Comment 14 commit-hook freebsd_committer 2021-11-21 02:40:39 UTC
A commit in branch main references this bug:

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

commit f0a3f8e66866cb022f8405a4a2772836a1f06de7
Author:     Jan Beich <jbeich@FreeBSD.org>
AuthorDate: 2021-11-20 23:41:56 +0000
Commit:     Jan Beich <jbeich@FreeBSD.org>
CommitDate: 2021-11-21 02:39:17 +0000

    www/firefox: unbreak PipeWire support after 8691df3a5142

    libpipewire is used on demand via dlopen(). Currently, only enabled
    for WebRTC getUserMedia (screen capture) under Wayland.

    https://searchfox.org/mozilla-release/rev/e2929d8cad28/third_party/libwebrtc/webrtc/modules/desktop_capture/screen_capturer_linux.cc#28

    PR:             259621

 mail/thunderbird/Makefile                        |  2 +-
 mail/thunderbird/files/patch-pipewire_init (new) | 73 ++++++++++++++++++++++++
 www/firefox-esr/Makefile                         |  2 +-
 www/firefox-esr/files/patch-pipewire_init (new)  | 73 ++++++++++++++++++++++++
 www/firefox/Makefile                             |  1 +
 www/firefox/files/patch-pipewire_init (new)      | 73 ++++++++++++++++++++++++
 6 files changed, 222 insertions(+), 2 deletions(-)
Comment 15 commit-hook freebsd_committer 2021-11-21 05:11:02 UTC
A commit in branch 2021Q4 references this bug:

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

commit da2987316783339d1d74b9252e4f87233781d0c9
Author:     Jan Beich <jbeich@FreeBSD.org>
AuthorDate: 2021-11-20 23:41:56 +0000
Commit:     Jan Beich <jbeich@FreeBSD.org>
CommitDate: 2021-11-21 05:10:30 +0000

    www/firefox: unbreak PipeWire support after 8691df3a5142

    libpipewire is used on demand via dlopen(). Currently, only enabled
    for WebRTC getUserMedia (screen capture) under Wayland.

    https://searchfox.org/mozilla-release/rev/e2929d8cad28/third_party/libwebrtc/webrtc/modules/desktop_capture/screen_capturer_linux.cc#28

    PR:             259621
    (cherry picked from commit f0a3f8e66866cb022f8405a4a2772836a1f06de7)

 mail/thunderbird/Makefile                        |  2 +-
 mail/thunderbird/files/patch-pipewire_init (new) | 73 ++++++++++++++++++++++++
 www/firefox-esr/Makefile                         |  2 +-
 www/firefox-esr/files/patch-pipewire_init (new)  | 73 ++++++++++++++++++++++++
 www/firefox/Makefile                             |  1 +
 www/firefox/files/patch-pipewire_init (new)      | 73 ++++++++++++++++++++++++
 6 files changed, 222 insertions(+), 2 deletions(-)
Comment 16 Gleb Popov freebsd_committer 2021-11-21 13:41:15 UTC
Ouch, sorry for committing this without bumping consumers.

/me puts on the largest pointy hat he has.