Bug 257798 – [GTK] Slow to create WebKitWebView (30 seconds delay) with sandbox

• Status: RESOLVED
• Resolution: MOVED
• Component: WebKitGTK

[Milan Crha]

Moving this from a downstream bug report:
https://gitlab.gnome.org/GNOME/evolution/-/issues/2393

A user reported a problem with Evolution opening message composer very slowly, like 30 seconds delay. It happens after update, which involved webkit2gtk (2.40.1-1 -> 2.40.1-2), but downgrading doesn't help, thus it's probably with some dependency.

The code behaves properly when Evolution is started with WEBKIT_DISABLE_SANDBOX_THIS_IS_DANGEROUS=1 exported.

There is a speculation that the 30 seconds delay may or may not be related to some D-Bus service/call timeout, but it's only a wild guess.

See the downstream bug report for more details, please.

[Michael Catanzaro]

We need to figure out more precisely where it is stalling for this user. My usual option would be to rebuild WebKit with added prints, but in this case it _might_ be possible to guess what's going wrong by using Bustle or dbus-monitor.

We probably need the affected user here on WebKit Bugzilla though, since nobody else will be able to debug this.

[roded]

Created attachment 466616 [details]
sandbox enabled

[roded]

Created attachment 466617 [details]
sandbox disabled

[roded]

Hello,
I am the affected user.
Attached two bustle pcap files for the same action in evolution (clicking the reply button for an email and waiting for the webkit window to become usable).

Please let me know if I could provide anything else.

Thank you.

[Michael Catanzaro]

Huh, nice, I can open those in Bustle and easily see exactly what's going on. I didn't realize how good Bustle was for debugging.

Unfortunately this session bus capture shows a 10 second delay in between *different* method calls, so now we know that nothing is going wrong on the session bus. That's where I would have expected to find any D-Bus problems, but there could also possibly be problems on the system bus (although this is less likely), so could try checking that too. There could also be a problem on the accessibility bus; you can trace that too using Bustle if you get its address:

$ echo $AT_SPI_BUS_ADDRESS

The environment variable probably won't be set. If not, you can do:

$ gdbus call --session --dest org.a11y.Bus --object-path /org/a11y/bus --method org.a11y.Bus.GetAddress

That should give you an address that you can pass to bustle to get a recording of the accessibility bus.

Most likely, these recordings won't reveal any problems, but it's at least worth a try. Maybe we'll get lucky.

One thing I notice is that you use Xfce, which is not a common desktop. WebKit ought to work fine in Xfce, but maybe whatever is wrong might be related to that.

[roded]

Created attachment 466625 [details]
accessibility-bus-trace

[roded]

Following your instructions Michael, I've attached accessibility-bus-trace for a similar action in evolution.

[Michael Catanzaro]

That looks fine too. You didn't attach a trace for the system bus, but it's probably also fine. So the D-Bus timeout theory (which seemed good) is not the problem.

Can you reproduce the problem by using `/usr/lib/webkit2gtk-4.1/MiniBrowser --enable-sandbox`? Try running MiniBrowser (preferably) or Evolution (if you can't reproduce with MiniBrowser) under strace. See if you can divide up the strace output into three sections: stuff that happens before the big hang, stuff that happens during the big hang, and stuff that that happens after the big hang. Hopefully there is not much going on when it hangs and we'll be able to get some clue from the strace output.

[roded]

Created attachment 466626 [details]
minibrowser-strace.log

[roded]

Yes, it does reproduce with MiniBrowser:

strace -to strace.log /usr/lib/webkit2gtk-4.1/MiniBrowser --enable-sandbox

The big hang seems to be this poll:

21:18:45 poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=8, events=POLLIN}], 3, 16150) = 0 (Timeout)
21:19:02 clock_gettime(CLOCK_MONOTONIC, {tv_sec=40903, tv_nsec=956684858}) = 0

And another one here:

21:19:11 clock_gettime(CLOCK_MONOTONIC, {tv_sec=40912, tv_nsec=955350309}) = 0
21:19:11 poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=8, events=POLLIN}], 3, -1) = 1 ([{fd=4, revents=POLLIN}])
21:19:36 read(4, "\1\0\0\0\0\0\0\0", 8) = 8

Thanks again for the attention to this.

[Michael Catanzaro]

(In reply to roded from comment #10)
> Yes, it does reproduce with MiniBrowser:
> 
> strace -to strace.log /usr/lib/webkit2gtk-4.1/MiniBrowser --enable-sandbox
> 
> The big hang seems to be this poll:
> 
> 21:18:45 poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=8,
> events=POLLIN}], 3, 16150) = 0 (Timeout)

Yeah that's surely the problem. The call to poll() is set to block for 16.15 seconds. Normally I would expect to see a non-blocking poll() so that the application does not hang. (16150 milliseconds is also a pretty strange choice of timeout. Where is that coming from?)

fd 3 is the X server connection, abstract socket @"/tmp/.X11-unix/X0", created here (right after the last previous fd 3 is closed):

21:18:45 close(3)
21:18:45 socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0) = 3
21:18:45 connect(3, {sa_family=AF_UNIX, sun_path=@"/tmp/.X11-unix/X0"}, 20) = 0

fd 4 is an eventfd, created here:

21:18:45 futex(0x7fe1a2f18fd8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
21:18:45 eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK) = 4
21:18:45 futex(0x7fe1a2f18fd8, FUTEX_WAKE_PRIVATE, 2147483647) = 0

I don't know what that is for, which is bad because it's probably important.

Then fd 8 is the accessibility bus connection:

21:18:45 close(8)                       = 0
21:18:45 socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0) = 8
21:18:45 connect(8, {sa_family=AF_UNIX, sun_path="/run/user/1000/at-spi/bus_0"}, 29) = 0

and we know your a11y bus is working fine because you attached the bustle pcap showing so in comment #6. So we do a blocking poll of the X server, the mysterious eventfd, and the a11y bus, waiting for data to be read from at least one of those three places. But why, and why does it fail?

I'm still stumped, but I have one more suggestion. Try this strace again, but this time use `strace --follow-forks --output-separately` to show all subprocesses. I see more subprocesses are launched than I would have expected. Perhaps we are missing a clue from a child process.

[roded]

Created attachment 466633 [details]
strace-follow-forks.tar.gz

[roded]

strace --follow-forks --output-separately -to strace-follow-forks.log /usr/lib/webkit2gtk-4.1/MiniBrowser --enable-sandbox

Attached strace-follow-forks.tar.gz which has quite a lot of files.

A big hang is in strace-follow-forks.log.166034:

08:33:50 poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=8, events=POLLIN}], 3, 13934) = 0 (Timeout)
08:34:04 clock_gettime(CLOCK_MONOTONIC, {tv_sec=81405, tv_nsec=955074978}) = 0

[Michael Catanzaro]

(In reply to roded from comment #13)
> which has quite a lot of files.

Wow, what is going on here? That's a *lot* of subprocesses. I wish we had some way to identify what these all are. :/

> A big hang is in strace-follow-forks.log.166034:
> 
> 08:33:50 poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=8,
> events=POLLIN}], 3, 13934) = 0 (Timeout)
> 08:34:04 clock_gettime(CLOCK_MONOTONIC, {tv_sec=81405, tv_nsec=955074978}) =
> 0

That's the same hang we were looking at above. I was hoping there would be only a few other processes and that one of them would contain some sort of clue. Drat.

I'm not sure what to try next. sysprof will probably not reveal anything interesting, since the UI process is clearly blocked doing a poll().

[roded]

Thanks for the effort Michael.
I'll update this ticket if anything new turns up.

[gkatev]

Hi, I'm also suffering from a similar/same bug. I found this issue through evolution's page, as I first encountered it in evolution (slow launch, slow message open), but it also happens in eog, evince, firefox, file-roller, and is not necessarily tied to sandboxing.

During the launch of these applications, they hang for 25 seconds evidently at a poll call, and then open properly. I used an LD_PRELOAD-based approach to capture where this poll is in the source code. I'm attaching coredumps/back-traces for eog and evolution, as well as the small program I used to get them.

Please let me know if this helps, if I can test something else, or if the problem I see is not actually related to this issue.

[gkatev]

Created attachment 466692 [details]
evolution eog poll stack traces

coredumps + backtraces + LD_PRELOAD program

[Michael Catanzaro]

Hm, I doubt you have the exact same issue as roded because his issue goes away when the WebKit sandbox is disabled, whereas your issue occurs in several applications that do not use WebKit at all.

That said:

 * Very good idea. Using LD_PRELOAD to replace poll() was smart and that's surely what roded will want to try to debug this further.
 * Your problem is caused by g_dbus_proxy_new_sync() timing out when trying to connect to the inhibit portal (evolution) or the settings portal (eog).
   * This is almost certainly a bug in xdg-desktop-portal (although theoretically something could be going wrong with the message bus, either dbus-daemon or dbus-broker depending on your distro).
   * Next step for you is a bug report to xdg-desktop-portal. Attaching to that process with gdb to see what it's doing at the time of the stall might help.

roded, you might be able to get the same quality backtrace more simply by attaching to the Evolution process with `sudo gdb -p` when it stalls, then entering `bt full` at the gdb prompt. In retrospect, I should have asked you to try that first, since you have a long window of time in which the stall occurs for you to attach.

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #18)
>  * Very good idea. Using LD_PRELOAD to replace poll() was smart and that's
> surely what roded will want to try to debug this further.

Um, just try attaching with gdb first. I think that will suffice to show what's going wrong.

[gkatev]

Thank you! Indeed it was a problem related to xdg-desktop-portal. For future internet wanderers: https://github.com/flatpak/xdg-desktop-portal/issues/1032. The problem was that there was xdg-desktop-portal-gnome installed on my system, even though I don't have gnome. This would never start (because I don't have gnome), and xdg-desktop-portal apparently waited for it and ultimately failed after 25s, instead of skipping it (!). Anyway, I fixed it by removing xdg-desktop-portal-gnome (I'm running cinnamon).

I don't know if this issue is at all related to xdg-desktop-portal. Indeed also on my system, the MiniBrowser hanged at the beginning with '--enable-sandbox', and didn't without it, and it stopped hanging after I removed xdg-desktop-portal-gnome.

Useful commands to look for xdg-desktop-portal issues like the one I encountered: 'journalctl -f', 'systemctl --user status xdg-desktop-portal', 'ls /usr/share/xdg-desktop-portal/portals', '/usr/lib/xdg-desktop-portal -v'.

[roded]

Attaching gdb shows a trace of new threads being created and exiting.

Hoping I did this right:

After clicking the reply button and before the composer window has appeared bt full shows:

#0  0x00007fcd9b513c0f in poll () at /usr/lib/libc.so.6
#1  0x00007fcda02d917f in  () at /usr/lib/libglib-2.0.so.0
#2  0x00007fcda027bc7f in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#3  0x00007fcd9fbd8e4f in gtk_main () at /usr/lib/libgtk-3.so.0
#4  0x000055ef0cd8957f in main ()

Once the composer window has appeared, but before the HTML is properly formatted, bt full shows:

#0  0x00007fcd9b513c0f in poll () at /usr/lib/libc.so.6
#1  0x00007fcda02d917f in  () at /usr/lib/libglib-2.0.so.0
#2  0x00007fcda027bc7f in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#3  0x00007fcd88a46ff5 in  () at /usr/lib/evolution/modules/module-webkit-editor.so
#4  0x00007fcd88a47a95 in  () at /usr/lib/evolution/modules/module-webkit-editor.so
#5  0x00007fcd88c04f5b in  () at /usr/lib/evolution/libevolution-mail-composer.so
#6  0x00007fcd9f697a23 in g_simple_async_result_complete () at /usr/lib/libgio-2.0.so.0
#7  0x00007fcd9f697aae in  () at /usr/lib/libgio-2.0.so.0
#8  0x00007fcda027c53b in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
#9  0x00007fcda02d9219 in  () at /usr/lib/libglib-2.0.so.0
#10 0x00007fcda027bc7f in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#11 0x00007fcd9fbd8e4f in gtk_main () at /usr/lib/libgtk-3.so.0
#12 0x000055ef0cd8957f in main ()

Thanks!

[Michael Catanzaro]

(In reply to roded from comment #21)
> Attaching gdb shows a trace of new threads being created and exiting.
> 
> Hoping I did this right:
> 
> After clicking the reply button and before the composer window has appeared
> bt full shows:
> 
> #0  0x00007fcd9b513c0f in poll () at /usr/lib/libc.so.6
> #1  0x00007fcda02d917f in  () at /usr/lib/libglib-2.0.so.0
> #2  0x00007fcda027bc7f in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
> #3  0x00007fcd9fbd8e4f in gtk_main () at /usr/lib/libgtk-3.so.0
> #4  0x000055ef0cd8957f in main ()

Well unfortunately that doesn't tell us anything.

> Once the composer window has appeared, but before the HTML is properly
> formatted, bt full shows:
> 
> #0  0x00007fcd9b513c0f in poll () at /usr/lib/libc.so.6
> #1  0x00007fcda02d917f in  () at /usr/lib/libglib-2.0.so.0
> #2  0x00007fcda027bc7f in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
> #3  0x00007fcd88a46ff5 in  () at
> /usr/lib/evolution/modules/module-webkit-editor.so
> #4  0x00007fcd88a47a95 in  () at
> /usr/lib/evolution/modules/module-webkit-editor.so
> #5  0x00007fcd88c04f5b in  () at
> /usr/lib/evolution/libevolution-mail-composer.so
> #6  0x00007fcd9f697a23 in g_simple_async_result_complete () at
> /usr/lib/libgio-2.0.so.0
> #7  0x00007fcd9f697aae in  () at /usr/lib/libgio-2.0.so.0
> #8  0x00007fcda027c53b in g_main_context_dispatch () at
> /usr/lib/libglib-2.0.so.0
> #9  0x00007fcda02d9219 in  () at /usr/lib/libglib-2.0.so.0
> #10 0x00007fcda027bc7f in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
> #11 0x00007fcd9fbd8e4f in gtk_main () at /usr/lib/libgtk-3.so.0
> #12 0x000055ef0cd8957f in main ()
> 
> Thanks!

Is this where the hang occurs?

Normally this is where I'd ask you to install debuginfo to get a better backtrace, but has to be coming from e-webkit-editor.c's webkit_editor_call_jsc_sync(). That's a nested main loop using the *default* GMainContext, so it's being iterated twice at the same time. Generally code does not expect this to happen, and all sorts of stuff can go wrong, so this is frowned upon.

I'd suggest, for starters, not doing that: create a new GMainContext instead, push thread-default, use it to create the GMainLoop, and pop thread-default when you're done. But I'm not sure if that's actually possible here, because if you *don't* iterate the default GMainContext here, then pearhps the call to webkit_web_view_run_javascript() will just not complete. Not sure. Anyway, that's the first thing I would try

[Milan Crha]

> Is this where the hang occurs?

This is not the problem. The code just waits to have the JavaScript call finished (it sometimes needs to do the call synchronously, which is tricky). It can be waiting on the WebKitWebProcess there. And yes, creating a new main context doesn't work, because D-Bus calls receive replies in the main main context, which would block the delivery here.

Either the corresponding WebKitWebProcess (beware, there are many running) is stuck on something, which means to get a backtrace of it, or the blocking thing happens in a different thread.

Try to use:

   gdb --batch --ex "t a a bt" --pid=PID &>bt.txt

to get backtrace of all the threads for the process with ID `PID`. At least for Evolution itself, please check the bt.txt for any private information, like passwords, email addresses, server addresses,... I usually search for "pass" at least (quotes for clarity only), before sharing it anywhere. There might be nothing shown with zero debuginfo installed though.

[roded]

Hi,
Giving it a shot with MiniBrowser, not sure I got this right, please let me know otherwise.

Executed /usr/lib/webkit2gtk-4.1/MiniBrowser --enable-sandbox and while it was loading, started gdb:

sudo DEBUGINFOD_URLS="https://debuginfod.archlinux.org/" gdb --pid=360894

This GDB supports auto-downloading debuginfo from the following URLs:
  <https://debuginfod.archlinux.org>
Enable debuginfod for this session? (y or [n]) y
Debuginfod has been enabled.
To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
0x00007f3ed7f13c0f in __GI___poll (fds=0x562f86803200, nfds=3, timeout=13096) at ../sysdeps/unix/sysv/linux/poll.c:29
29        return SYSCALL_CANCEL (poll, fds, nfds, timeout);
(gdb) t a a bt

Thread 12 (Thread 0x7f3e5f7fe6c0 (LWP 370673) "ReceiveQueue"):
#0  0x00007f3ed7f13c0f in __GI___poll (fds=0x7f3e50039970, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007f3ede23e17f in  () at /usr/lib/libglib-2.0.so.0
#2  0x00007f3ede1e0c7f in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#3  0x00007f3ed91137d2 in WTF::RunLoop::run() () at /usr/lib/libjavascriptcoregtk-4.1.so.0
#4  0x00007f3ed91152cd in  () at /usr/lib/libjavascriptcoregtk-4.1.so.0
#5  0x00007f3ed7e9d44b in start_thread (arg=<optimized out>) at pthread_create.c:444
#6  0x00007f3ed7f20e40 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 11 (Thread 0x7f3e5ffff6c0 (LWP 370672) "ReceiveQueue"):
#0  0x00007f3ed7f13c0f in __GI___poll (fds=0x7f3e58023510, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007f3ede23e17f in  () at /usr/lib/libglib-2.0.so.0
#2  0x00007f3ede1e0c7f in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#3  0x00007f3ed91137d2 in WTF::RunLoop::run() () at /usr/lib/libjavascriptcoregtk-4.1.so.0
#4  0x00007f3ed91152cd in  () at /usr/lib/libjavascriptcoregtk-4.1.so.0
#5  0x00007f3ed7e9d44b in start_thread (arg=<optimized out>) at pthread_create.c:444
#6  0x00007f3ed7f20e40 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 10 (Thread 0x7f3e5effd6c0 (LWP 370657) "pool-MiniBrowse"):
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x00007f3ede237d03 in g_cond_wait_until () at /usr/lib/libglib-2.0.so.0
#2  0x00007f3ede1abf83 in  () at /usr/lib/libglib-2.0.so.0
#3  0x00007f3ede1ac127 in g_async_queue_timeout_pop () at /usr/lib/libglib-2.0.so.0
#4  0x00007f3ede213846 in  () at /usr/lib/libglib-2.0.so.0
#5  0x00007f3ede20e315 in  () at /usr/lib/libglib-2.0.so.0
#6  0x00007f3ed7e9d44b in start_thread (arg=<optimized out>) at pthread_create.c:444
#7  0x00007f3ed7f20e40 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 9 (Thread 0x7f3e6cffb6c0 (LWP 370651) "IconDatabase"):
#0  0x00007f3ed7f13c0f in __GI___poll (fds=0x7f3e64001020, nfds=1, timeout=10000) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007f3ede23e17f in  () at /usr/lib/libglib-2.0.so.0
#2  0x00007f3ede1e0c7f in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#3  0x00007f3ed91137d2 in WTF::RunLoop::run() () at /usr/lib/libjavascriptcoregtk-4.1.so.0
#4  0x00007f3ed91152cd in  () at /usr/lib/libjavascriptcoregtk-4.1.so.0
#5  0x00007f3ed7e9d44b in start_thread (arg=<optimized out>) at pthread_create.c:444
#6  0x00007f3ed7f20e40 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 8 (Thread 0x7f3e6d7fc6c0 (LWP 370650) "PressureMonitor"):
#0  0x00007f3ed7e99f0e in __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x7f3e6d7faee0, op=393, expected=0, futex_word=0x7f3ec1088160) at futex-internal.c:57
#1  __futex_abstimed_wait_common (futex_word=futex_word@entry=0x7f3ec1088160, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x7f3e6d7faee0, private=private@entry=0, cancel=cancel@entry=true) at futex-internal.c:87
--Type <RET> for more, q to quit, c to continue without paging--
#2  0x00007f3ed7e99f8f in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x7f3ec1088160, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x7f3e6d7faee0, private=private@entry=0) at futex-internal.c:139
#3  0x00007f3ed7e9cab5 in __pthread_cond_wait_common (abstime=0x7f3e6d7faee0, clockid=0, mutex=0x7f3ec1088110, cond=0x7f3ec1088138) at pthread_cond_wait.c:503
#4  ___pthread_cond_timedwait64 (cond=0x7f3ec1088138, mutex=0x7f3ec1088110, abstime=0x7f3e6d7faee0) at pthread_cond_wait.c:643
#5  0x00007f3ed9126f0e in WTF::ThreadCondition::timedWait(WTF::Mutex&, WTF::WallTime) () at /usr/lib/libjavascriptcoregtk-4.1.so.0
#6  0x00007f3ed90ba445 in WTF::ParkingLot::parkConditionallyImpl(void const*, WTF::ScopedLambda<bool ()> const&, WTF::ScopedLambda<void ()> const&, WTF::TimeWithDynamicClockType const&) () at /usr/lib/libjavascriptcoregtk-4.1.so.0
#7  0x00007f3ed90dd34d in WTF::sleep(WTF::Seconds) () at /usr/lib/libjavascriptcoregtk-4.1.so.0
#8  0x00007f3edaee9331 in  () at /usr/lib/libwebkit2gtk-4.1.so.0
#9  0x00007f3edaeea653 in  () at /usr/lib/libwebkit2gtk-4.1.so.0
#10 0x00007f3ed91152cd in  () at /usr/lib/libjavascriptcoregtk-4.1.so.0
#11 0x00007f3ed7e9d44b in start_thread (arg=<optimized out>) at pthread_create.c:444
#12 0x00007f3ed7f20e40 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 7 (Thread 0x7f3e6dffd6c0 (LWP 370648) "ebsiteDataStore"):
#0  0x00007f3ed7f13c0f in __GI___poll (fds=0x7f3e60001020, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007f3ede23e17f in  () at /usr/lib/libglib-2.0.so.0
#2  0x00007f3ede1e0c7f in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#3  0x00007f3ed91137d2 in WTF::RunLoop::run() () at /usr/lib/libjavascriptcoregtk-4.1.so.0
#4  0x00007f3ed91152cd in  () at /usr/lib/libjavascriptcoregtk-4.1.so.0
#5  0x00007f3ed7e9d44b in start_thread (arg=<optimized out>) at pthread_create.c:444
#6  0x00007f3ed7f20e40 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 6 (Thread 0x7f3ec0ffd6c0 (LWP 370647) "HashSaltStorage"):
#0  0x00007f3ed7f13c0f in __GI___poll (fds=0x7f3e68001020, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007f3ede23e17f in  () at /usr/lib/libglib-2.0.so.0
#2  0x00007f3ede1e0c7f in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#3  0x00007f3ed91137d2 in WTF::RunLoop::run() () at /usr/lib/libjavascriptcoregtk-4.1.so.0
#4  0x00007f3ed91152cd in  () at /usr/lib/libjavascriptcoregtk-4.1.so.0
#5  0x00007f3ed7e9d44b in start_thread (arg=<optimized out>) at pthread_create.c:444
#6  0x00007f3ed7f20e40 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 5 (Thread 0x7f3ec37fe6c0 (LWP 370646) "MiniBrowser"):
#0  0x00007f3ed7e99f0e in __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x7f3ec37fd2c0, op=393, expected=0, futex_word=0x7f3eb000e990) at futex-internal.c:57
#1  __futex_abstimed_wait_common (futex_word=futex_word@entry=0x7f3eb000e990, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x7f3ec37fd2c0, private=private@entry=0, cancel=cancel@entry=true) at futex-internal.c:87
#2  0x00007f3ed7e99f8f in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x7f3eb000e990, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x7f3ec37fd2c0, private=private@entry=0) at futex-internal.c:139
#3  0x00007f3ed7e9cab5 in __pthread_cond_wait_common (abstime=0x7f3ec37fd2c0, clockid=0, mutex=0x7f3eb000e940, cond=0x7f3eb000e968) at pthread_cond_wait.c:503
#4  ___pthread_cond_timedwait64 (cond=0x7f3eb000e968, mutex=0x7f3eb000e940, abstime=0x7f3ec37fd2c0) at pthread_cond_wait.c:643
#5  0x00007f3ed91788ec in  () at /usr/lib/libjavascriptcoregtk-4.1.so.0
#6  0x00007f3ed7e9d44b in start_thread (arg=<optimized out>) at pthread_create.c:444
--Type <RET> for more, q to quit, c to continue without paging--
#7  0x00007f3ed7f20e40 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 4 (Thread 0x7f3ec3fff6c0 (LWP 370645) "gdbus"):
#0  0x00007f3ed7f13c0f in __GI___poll (fds=0x7f3eb8000b90, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007f3ede23e17f in  () at /usr/lib/libglib-2.0.so.0
#2  0x00007f3ede1e0c7f in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#3  0x00007f3ed990ed3c in  () at /usr/lib/libgio-2.0.so.0
#4  0x00007f3ede20e315 in  () at /usr/lib/libglib-2.0.so.0
#5  0x00007f3ed7e9d44b in start_thread (arg=<optimized out>) at pthread_create.c:444
#6  0x00007f3ed7f20e40 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 3 (Thread 0x7f3ec8fc16c0 (LWP 370644) "gmain"):
#0  0x00007f3ed7f13c0f in __GI___poll (fds=0x7f3ebc000b90, nfds=5, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007f3ede23e17f in  () at /usr/lib/libglib-2.0.so.0
#2  0x00007f3ede1e01a2 in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0
#3  0x00007f3ede1e01f2 in  () at /usr/lib/libglib-2.0.so.0
#4  0x00007f3ede20e315 in  () at /usr/lib/libglib-2.0.so.0
#5  0x00007f3ed7e9d44b in start_thread (arg=<optimized out>) at pthread_create.c:444
#6  0x00007f3ed7f20e40 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 2 (Thread 0x7f3ec97c26c0 (LWP 370643) "pool-spawner"):
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x00007f3ede2377b5 in g_cond_wait () at /usr/lib/libglib-2.0.so.0
#2  0x00007f3ede1abfb4 in  () at /usr/lib/libglib-2.0.so.0
#3  0x00007f3ede212f9e in  () at /usr/lib/libglib-2.0.so.0
#4  0x00007f3ede20e315 in  () at /usr/lib/libglib-2.0.so.0
#5  0x00007f3ed7e9d44b in start_thread (arg=<optimized out>) at pthread_create.c:444
#6  0x00007f3ed7f20e40 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 1 (Thread 0x7f3eca0a1300 (LWP 370642) "MiniBrowser"):
#0  0x00007f3ed7f13c0f in __GI___poll (fds=0x562f86803200, nfds=3, timeout=13096) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007f3ede23e17f in  () at /usr/lib/libglib-2.0.so.0
#2  0x00007f3ede1e01a2 in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0
#3  0x00007f3ed98dc3be in g_application_run () at /usr/lib/libgio-2.0.so.0
#4  0x0000562f8461e2ef in  ()
#5  0x00007f3ed7e39850 in __libc_start_call_main (main=main@entry=0x562f8461e020, argc=argc@entry=2, argv=argv@entry=0x7ffd56935f48) at ../sysdeps/nptl/libc_start_call_main.h:58
#6  0x00007f3ed7e3990a in __libc_start_main_impl (main=0x562f8461e020, argc=2, argv=0x7ffd56935f48, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffd56935f38) at ../csu/libc-start.c:360
#7  0x0000562f8461e4a5 in  ()

[Michael Catanzaro]

(In reply to roded from comment #24)
> Thread 1 (Thread 0x7f3eca0a1300 (LWP 370642) "MiniBrowser"):
> #0  0x00007f3ed7f13c0f in __GI___poll (fds=0x562f86803200, nfds=3,
> timeout=13096) at ../sysdeps/unix/sysv/linux/poll.c:29

Unfortunately this just tells us what we already knew. :/ WebKit is waiting an inordinately long time for a response that is not forthcoming. But we don't know what it's waiting for.

You don't have xdg-desktop-portal-gnome installed like gkatev did, do you?

[roded]

I did have xdg-desktop-portal-gnome installed!
Once removed the issue is resolved.
Thanks a lot!

[Michael Catanzaro]

OK, please first make sure you have the latest release of xdg-desktop-portal and xdg-desktop-portal-gnome, because similar problems were fixed recently. Assuming you have the latest release, then you can report a bug to xdg-desktop-portal-gnome because this is not an acceptable user experience.