xdg-desktop-portal coredump in xdp_documents_get_version when used with flatpak

[sochotnicky]

I was playing with https://github.com/bottlesdevs/Bottles flatpak, and noticed that xdg-desktop-portal coredumps.

Traceback:

#0  0x0000560253652349 in xdp_documents_get_version (object=0x0) at src/xdp-dbus.c:6539
^[[A^[[B6539     return XDP_DOCUMENTS_GET_IFACE (object)->get_version (object);
[Current thread is 1 (Thread 0x7fe71d910640 (LWP 11694))]
(gdb) bt full
#0  0x0000560253652349 in xdp_documents_get_version (object=0x0) at src/xdp-dbus.c:6539
#1  0x000056025362fda6 in register_document
    (uri=<optimized out>, app_id=0x7fe714009140 "com.usebottles.bottles", for_save=for_save@entry=0, writable=<optimized out>, writable@entry=1, directory=directory@entry=0, error=error@entry=0x7fe71d90fca8) at src/documents.c:110
        doc_id = 0x0
        doc_ids = 0x0
        path = 0x7fe71400b480 "/tmp/winbox.exe"
        basename = 0x7fe71400b680 "winbox.exe"
        dirname = 0x7fe71400a360 "/tmp"
        fd_list = 0x7fe710005170
        fd = 23
        fd_in = 0
        file = 0x7fe71400c740
        ret = 0
        permissions = 
          {0x5602536a7050 "read", 0x5602536a4003 "write", 0x5602536a6fe7 "grant-permissions", 0x0, 0x7fe71d90fd30 ""}
        doc_path = 0x0
        i = 4
        version = <optimized out>
        handled_permissions = 0
        full_flags = <optimized out>
#2  0x0000560253624205 in send_response_in_thread_func
    (task=<optimized out>, source_object=<optimized out>, task_data=0x7fe710003e90, cancellable=<optimized out>)
    at src/file-chooser.c:116
        ruri = 0x0
        error = 0x0
        i = 0
        request = 0x7fe710003e90
        results = 
              {u = {s = {partial_magic = 0, type = 0x7fe710012060, y = {140630382682209, 140630382647472, 0, 18446744073709551615, 140630382698944, 8, 1, 3, 1033660112, 0, 0, 0, 0, 0}}, x = {0, 140630382682208, 140630382682209, 140630382647472, 0, 18446744073709551615, 140630382698944, 8, 1, 3, 1033660112, 0, 0, 0, 0, 0}}}
        ruris = 
              {u = {s = {partial_magic = 0, type = 0x7fe71400b540, y = {140630449763649, 0, 0, 18446744073709551615, 140630382682128, 8, 0, 3, 1033660112, 0, 0, 0, 0, 0}}, x = {0, 140630449763648, 140630449763649, 0, 0, 18446744073709551615, 140630382682128, 8, 0, 3, 1033660112, 0, 0, 0, 0, 0}}}
        response = <optimized out>
        options = <optimized out>
        writable = 1
        directory = 0
        uris = 0x7fe71400deb0
        choices = <optimized out>
        for_save = 0
        current_filter = <optimized out>
        request_auto_unlock86 = 0x7fe710003ed0
#3  0x00007fe71f7d3d54 in  () at /usr/lib64/libgio-2.0.so.0
#4  0x00007fe71f611a14 in  () at /usr/lib64/libglib-2.0.so.0
#5  0x00007fe71f61107d in  () at /usr/lib64/libglib-2.0.so.0
#6  0x00007fe71f490cfe in start_thread (arg=0x7fe71d910640) at pthread_create.c:481
        ret = <optimized out>
        pd = 0x7fe71d910640
        unwind_buf = 
              {cancel_jmp_buf = {{jmp_buf = {140630610216512, 2332940343075171770, 140728889042174, 140728889042175, 0, 140630610216512, -2328783493285515846, -2328789319881036358}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = 0
#7  0x00007fe71f3c524f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

xdg-desktop-portal version 1.10.1 xdg-desktop-portal-wlr 0.5.0 (on sway) xdg-desktop-portal-gtk 1.8.0 kernel 5.15.4 (I had a weird kernel crash when running the same flatpak on 5.15.3 but that might be a red herring - if interested some details about that are in https://bugs.gentoo.org/826878)

This might be a duplicate/similar to https://github.com/flatpak/xdg-desktop-portal/issues/664 but in my case it's not crashing in libglib so filed a separate issue.

I can reproduce quite reliably and can provide actual coredump somewhere (it is 60MB so I didn't attach it)

[smcv]

xdg-desktop-portal version 1.10.1

What distribution? Any distro patches applied?

register_document() assumes that the global documents object is non-NULL, but in your case it's NULL. This means the xdp_documents_proxy_new_sync() call in init_document_proxy failed. There should be error-checking for that, but at the moment there isn't.

kernel 5.15.4 (I had a weird kernel crash when running the same flatpak on 5.15.3 but that might be a red herring - if interested some details about that are in https://bugs.gentoo.org/826878)

I wonder whether this is the same kernel regression mentioned in https://github.com/flatpak/flatpak/issues/4595.

[smcv]

xdg-desktop-portal should have error-handling for xdp_documents_proxy_new_sync() having failed, but it's possible that a fixed kernel would mean that xdp_documents_proxy_new_sync() didn't fail in practice.

[sochotnicky]

xdg-desktop-portal version 1.10.1

What distribution? Any distro patches applied?

Gentoo - no patches are being applied, there's a minor tweak to locales: https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-apps/flatpak/flatpak-1.10.5.ebuild

Edit: Bah, it's getting late - no patches applied here: https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-apps/xdg-desktop-portal/xdg-desktop-portal-1.10.1.ebuild

register_document() assumes that the global documents object is non-NULL, but in your case it's NULL. This means the xdp_documents_proxy_new_sync() call in init_document_proxy failed. There should be error-checking for that, but at the moment there isn't.

kernel 5.15.4 (I had a weird kernel crash when running the same flatpak on 5.15.3 but that might be a red herring - if interested some details about that are in https://bugs.gentoo.org/826878)

I wonder whether this is the same kernel regression mentioned in flatpak/flatpak#4595.

Huh, the fuse_file_aops does appear in my backtrace too and the whole situation indeed looks very similar. From reading the RHBZ I guess the patch is just in fedora kernel for now, I'll see if I can dig it up and apply to my kernel to see if that will fix things.

[sochotnicky]

So I am now running kernel 5.15.6 (+ gentoo patches) and the behavior is unchanged/broken so guessing this is separate from the fix that landed there.

[GeorgesStavracas]

Is this still reproducible with xdg-desktop-portal 1.18 or git?