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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Jun 7 12:04:54 PDT 2023


https://bugs.webkit.org/show_bug.cgi?id=257798

--- Comment #11 from Michael Catanzaro <mcatanzaro at redhat.com> ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20230607/119c3096/attachment.htm>


More information about the webkit-unassigned mailing list