Date: Wed, 29 Jan 2020 19:51:01 +0000 From: greg@unrelenting.technology To: "Jan Beich" <jbeich@freebsd.org> Cc: "Christoph Moench-Tegeder" <cmt@burggraben.net>, ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: Re: svn commit: r516629 - head/net/liferea Message-ID: <9272c6b5423efa167198ce8cb6da42db@unrelenting.technology> In-Reply-To: <004506e3-be62-4533-b2d6-c3386121af0e@localhost> References: <004506e3-be62-4533-b2d6-c3386121af0e@localhost> <201911041019.xA4AJYqc047310@repo.freebsd.org> <20191104103901.GA2476@elch.exwg.net> <20200128001023.GA62291@elch.exwg.net> <pnf2-bm7z-wny@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
January 29, 2020 9:46 PM, "Greg V" <greg@unrelenting.technology> wrote:= =0A=0A> Jan 29, 2020 1:18:04 PM Jan Beich :=0A> =0A>> Christoph Moench-Te= geder writes:=0A>> =0A>> [ ... http://docs.freebsd.org/cgi/mid.cgi?202001= 28001023.GA62291 ... ]=0A>> =0A>> So, opinions against doing just that? I= 've no idea if it would even make=0A>> sense to try to support WPE on Fre= eBSD or if it's just something we=0A>> inherited "because it's there" as = someone upstream had declared=0A>> underpowered mobile devices to be the = future.=0A>> =0A>> WPE dependency was added in https://bugs.webkit.org/sh= ow_bug.cgi?id=3D197944=0A>> WPE renderer is unstable for me under Sway (W= ayland compositor) e.g.,=0A>> Midori hangs shortly after startup. Greg, c= an you confirm?=0A> =0A> Oh, that's why webkit has been broken for the la= st few months! Yeah, it's been causing serious=0A> issues on my machine, = i.e. if I accidentally started a webkit gtk app, the web content would be= =0A> blank and I couldn't kill it, otherwise it would cause something lik= e a GPU hang that amdgpu can't=0A> recover from, so I'd have to reboot.= =0A> =0A> So far I haven't bothered to investigate because I've been busy= with things (like improving Firefox=0A> :D), but I'll see if I can fix i= t. It's good that they have a renderer that's not doing the=0A> ridiculou= s nested compositor thing now, we should have that working.=0A=0ALOL, tes= ting on an Intel GPU laptop (where the system/gpu hang =C2=AD=E2=80=94 wh= ich is some unrelated amd issue =E2=80=94 does not apply) with MiniBrowse= r-4, turns out attaching a debugger (lldb) to the main browser process wh= en it's hanging and entering 'c' (continue) unfreezes it and everything w= orks.=0AThis is where it's hanging:=0A=0A * frame #0: 0x0000000806e957ca= libc.so.7`_kevent + 10=0A frame #1: 0x000000080316a783 libthr.so.3`__= _lldb_unnamed_symbol54$$libthr.so.3 + 83=0A frame #2: 0x000000080862aa= fb libepoll-shim.so.0`epoll_wait + 315=0A frame #3: 0x0000000806c3e9fd= libwayland-server.so.0`wl_event_loop_dispatch + 77=0A frame #4: 0x000= 0000807145128 libWPEBackend-fdo-1.0.so.1`___lldb_unnamed_symbol35$$libWPE= Backend-fdo-1.0.so.1 + 4=0A frame #5: 0x0000000803cec267 libglib-2.0.s= o.0`g_main_context_dispatch + 327=0A=0ALooking at the wpebackend-fdo sour= ce, it is indeed calling wl_event_loop_dispatch with -1 timeout (i.e. no = timeout).=0AReported: https://github.com/Igalia/WPEBackend-fdo/issues/94
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9272c6b5423efa167198ce8cb6da42db>