svn commit: r516629 - head/net/liferea
greg at unrelenting.technology
greg at unrelenting.technology
Wed Jan 29 19:51:06 UTC 2020
January 29, 2020 9:46 PM, "Greg V" <greg at unrelenting.technology> wrote:
> Jan 29, 2020 1:18:04 PM Jan Beich :
>
>> Christoph Moench-Tegeder writes:
>>
>> [ ... http://docs.freebsd.org/cgi/mid.cgi?20200128001023.GA62291 ... ]
>>
>> So, opinions against doing just that? I've no idea if it would even make
>> sense to try to support WPE on FreeBSD or if it's just something we
>> inherited "because it's there" as someone upstream had declared
>> underpowered mobile devices to be the future.
>>
>> WPE dependency was added in https://bugs.webkit.org/show_bug.cgi?id=197944
>> WPE renderer is unstable for me under Sway (Wayland compositor) e.g.,
>> Midori hangs shortly after startup. Greg, can you confirm?
>
> Oh, that's why webkit has been broken for the last few months! Yeah, it's been causing serious
> issues on my machine, i.e. if I accidentally started a webkit gtk app, the web content would be
> blank and I couldn't kill it, otherwise it would cause something like a GPU hang that amdgpu can't
> recover from, so I'd have to reboot.
>
> So far I haven't bothered to investigate because I've been busy with things (like improving Firefox
> :D), but I'll see if I can fix it. It's good that they have a renderer that's not doing the
> ridiculous nested compositor thing now, we should have that working.
LOL, testing on an Intel GPU laptop (where the system/gpu hang — which is some unrelated amd issue — does not apply) with MiniBrowser-4, turns out attaching a debugger (lldb) to the main browser process when it's hanging and entering 'c' (continue) unfreezes it and everything works.
This is where it's hanging:
* frame #0: 0x0000000806e957ca libc.so.7`_kevent + 10
frame #1: 0x000000080316a783 libthr.so.3`___lldb_unnamed_symbol54$$libthr.so.3 + 83
frame #2: 0x000000080862aafb libepoll-shim.so.0`epoll_wait + 315
frame #3: 0x0000000806c3e9fd libwayland-server.so.0`wl_event_loop_dispatch + 77
frame #4: 0x0000000807145128 libWPEBackend-fdo-1.0.so.1`___lldb_unnamed_symbol35$$libWPEBackend-fdo-1.0.so.1 + 4
frame #5: 0x0000000803cec267 libglib-2.0.so.0`g_main_context_dispatch + 327
Looking at the wpebackend-fdo source, it is indeed calling wl_event_loop_dispatch with -1 timeout (i.e. no timeout).
Reported: https://github.com/Igalia/WPEBackend-fdo/issues/94
More information about the svn-ports-all
mailing list