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