bug#52375: webkitgtk page crashes on core-updates-frozen

bug#52375: webkitgtk page crashes on core-updates-frozen

[Jack Hill]

Hi Guix,

With core-updates-frozen commit e080e35dc1f012fa57a8e77759f933abdc3b8fc2 
certain pages cause tabs to crash in webkitgtk browsers (I've tested with 
epiphany, vimb, and luakit). The problem does not occur on current master, 
0a9c946df9686f1610f7684492baabf0719c0164.

An example of a page the works:

https://en.wiktionary.org/wiki/edification

An example of a page that doesn't work:

https://en.wiktionary.org/wiki/edify

I was not able to notice a difference in messages when running the 
browsers from a terminal between master and core-updates-frozen.

On both branches I do see "WebKit wasn't able to find a WebVTT encoder. 
Not continuing without platform support for subtitles" when the tab 
crashes, so I wonder if there is a gstreamer compatibility problem 
(perhaps to do with libsoup versions). However, this could be a red 
herring.

Best,
Jack

bug#52375: webkitgtk page crashes on core-updates-frozen

[Maxim Cournoyer]

Hello!

Jack Hill <jackhill@jackhill.us> writes:

> Hi Guix,
>
> With core-updates-frozen commit
> e080e35dc1f012fa57a8e77759f933abdc3b8fc2 certain pages cause tabs to
> crash in webkitgtk browsers (I've tested with epiphany, vimb, and
> luakit). The problem does not occur on current master,
> 0a9c946df9686f1610f7684492baabf0719c0164.
>
> An example of a page the works:
>
> https://en.wiktionary.org/wiki/edification
>
> An example of a page that doesn't work:
>
> https://en.wiktionary.org/wiki/edify
>
> I was not able to notice a difference in messages when running the
> browsers from a terminal between master and core-updates-frozen.
>
> On both branches I do see "WebKit wasn't able to find a WebVTT
> encoder. Not continuing without platform support for subtitles" when
> the tab crashes, so I wonder if there is a gstreamer compatibility
> problem (perhaps to do with libsoup versions). However, this could be
> a red herring.

Would you be able to run it in GDB to gather a backtrace?  That may
provide clues.

Thanks!

Maxim

bug#52375: webkitgtk page crashes on core-updates-frozen

[Jack Hill]

On Wed, 8 Dec 2021, Maxim Cournoyer wrote:

> Hello!
>
> Would you be able to run it in GDB to gather a backtrace?  That may
> provide clues.
>
> Thanks!

Yes! I was albe to get the following backtrace. Thanks to hikiko [0] 
for tips on using GDB with WebKit browsers

[0] https://eleni.mutantstargoat.com/hikiko/webkit-gdb/


$ gdb .midori-real 1979
GNU gdb (GDB) 11.1
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
     <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from .midori-real...
(No debugging symbols found in .midori-real)
Attaching to program: /gnu/store/kz9inh53yvpzxv818jq6naiwp6ms85l0-midori-9.0/bin/.midori-real, process 1979
[New LWP 1981]
[New LWP 1983]
[New LWP 1984]
[New LWP 1985]
[New LWP 1986]
[New LWP 1987]
[New LWP 1988]
[New LWP 1992]
[New LWP 1993]
[New LWP 1994]
[New LWP 2001]

warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
0x00007f70beab5d6f in poll () from /gnu/store/2fk1gz2s7ppdicynscra9b19byrrr866-glibc-2.33/lib/libc.so.6
(gdb) c
Continuing.
[New LWP 2395]
[New LWP 2411]

Thread 1 "WebKitWebProces" received signal SIGABRT, Aborted.
0x00007f70bea04030 in raise () from /gnu/store/2fk1gz2s7ppdicynscra9b19byrrr866-glibc-2.33/lib/libc.so.6
(gdb) bt
#0  0x00007f70bea04030 in raise () from /gnu/store/2fk1gz2s7ppdicynscra9b19byrrr866-glibc-2.33/lib/libc.so.6
#1  0x00007f70be9ee526 in abort () from /gnu/store/2fk1gz2s7ppdicynscra9b19byrrr866-glibc-2.33/lib/libc.so.6
#2  0x00007f70c4089a52 in WebCore::makeGStreamerElement(char const*, char const*) [clone .cold] () from /gnu/store/77vf3q1v7aa8h2av7s10fn95b0crh7zc-webkitgtk-with-libsoup2-2.34.1/lib/libwebkit2gtk-4.0.so.37
#3  0x00007f70c63be439 in WebCore::MediaPlayerPrivateGStreamer::createVideoSink() () from /gnu/store/77vf3q1v7aa8h2av7s10fn95b0crh7zc-webkitgtk-with-libsoup2-2.34.1/lib/libwebkit2gtk-4.0.so.37
#4  0x00007f70c63c351f in WebCore::MediaPlayerPrivateGStreamer::createGSTPlayBin(WTF::URL const&) () from /gnu/store/77vf3q1v7aa8h2av7s10fn95b0crh7zc-webkitgtk-with-libsoup2-2.34.1/lib/libwebkit2gtk-4.0.so.37
#5  0x00007f70c63c442b in WebCore::MediaPlayerPrivateGStreamer::load(WTF::String const&) () from /gnu/store/77vf3q1v7aa8h2av7s10fn95b0crh7zc-webkitgtk-with-libsoup2-2.34.1/lib/libwebkit2gtk-4.0.so.37
#6  0x00007f70c5c7e19c in WebCore::MediaPlayer::loadWithNextMediaEngine(WebCore::MediaPlayerFactory const*) () from /gnu/store/77vf3q1v7aa8h2av7s10fn95b0crh7zc-webkitgtk-with-libsoup2-2.34.1/lib/libwebkit2gtk-4.0.so.37
#7  0x00007f70c5c7e76b in WebCore::MediaPlayer::load(WTF::URL const&, WebCore::ContentType const&, WTF::String const&) ()
    from /gnu/store/77vf3q1v7aa8h2av7s10fn95b0crh7zc-webkitgtk-with-libsoup2-2.34.1/lib/libwebkit2gtk-4.0.so.37
#8  0x00007f70c570d73d in WebCore::HTMLMediaElement::loadResource(WTF::URL const&, WebCore::ContentType&, WTF::String const&) ()
    from /gnu/store/77vf3q1v7aa8h2av7s10fn95b0crh7zc-webkitgtk-with-libsoup2-2.34.1/lib/libwebkit2gtk-4.0.so.37
#9  0x00007f70c570e3e1 in WebCore::HTMLMediaElement::loadNextSourceChild() () from /gnu/store/77vf3q1v7aa8h2av7s10fn95b0crh7zc-webkitgtk-with-libsoup2-2.34.1/lib/libwebkit2gtk-4.0.so.37
#10 0x00007f70c54fc3c2 in WebCore::EventLoop::run() () from /gnu/store/77vf3q1v7aa8h2av7s10fn95b0crh7zc-webkitgtk-with-libsoup2-2.34.1/lib/libwebkit2gtk-4.0.so.37
#11 0x00007f70c558a80d in WebCore::WindowEventLoop::didReachTimeToRun() () from /gnu/store/77vf3q1v7aa8h2av7s10fn95b0crh7zc-webkitgtk-with-libsoup2-2.34.1/lib/libwebkit2gtk-4.0.so.37
#12 0x00007f70c5bdaadc in WebCore::ThreadTimers::sharedTimerFiredInternal() () from /gnu/store/77vf3q1v7aa8h2av7s10fn95b0crh7zc-webkitgtk-with-libsoup2-2.34.1/lib/libwebkit2gtk-4.0.so.37
#13 0x00007f70c2a830f5 in WTF::RunLoop::TimerBase::TimerBase(WTF::RunLoop&)::{lambda(void*)#1}::_FUN(void*) ()
    from /gnu/store/77vf3q1v7aa8h2av7s10fn95b0crh7zc-webkitgtk-with-libsoup2-2.34.1/lib/libjavascriptcoregtk-4.0.so.18
#14 0x00007f70c2a8333f in WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)#1}::_FUN(_GSource*, int (*)(void*), void*) ()
    from /gnu/store/77vf3q1v7aa8h2av7s10fn95b0crh7zc-webkitgtk-with-libsoup2-2.34.1/lib/libjavascriptcoregtk-4.0.so.18
#15 0x00007f70bef5236f in g_main_context_dispatch () from /gnu/store/qqs98rxwjrji6aaf6dqwp7q4m545g2sn-glib-2.70.0/lib/libglib-2.0.so.0
#16 0x00007f70bef526e8 in g_main_context_iterate.constprop () from /gnu/store/qqs98rxwjrji6aaf6dqwp7q4m545g2sn-glib-2.70.0/lib/libglib-2.0.so.0
#17 0x00007f70bef529cb in g_main_loop_run () from /gnu/store/qqs98rxwjrji6aaf6dqwp7q4m545g2sn-glib-2.70.0/lib/libglib-2.0.so.0
#18 0x00007f70c2a83470 in WTF::RunLoop::run() () from /gnu/store/77vf3q1v7aa8h2av7s10fn95b0crh7zc-webkitgtk-with-libsoup2-2.34.1/lib/libjavascriptcoregtk-4.0.so.18
#19 0x00007f70c47e5c81 in WebKit::WebProcessMain(int, char**) () from /gnu/store/77vf3q1v7aa8h2av7s10fn95b0crh7zc-webkitgtk-with-libsoup2-2.34.1/lib/libwebkit2gtk-4.0.so.37
#20 0x00007f70be9ef7dd in __libc_start_main () from /gnu/store/2fk1gz2s7ppdicynscra9b19byrrr866-glibc-2.33/lib/libc.so.6
#21 0x000000000040107a in main ()
(gdb)

bug#52375: Both pages load fine for me

[Vivien Kraus via Bug reports for GNU Guix]

[-- Attachment #1: Type: text/plain, Size: 202 bytes --]

Dear guix,

As a guix home user on a GNOME guix system, both pages work in epiphany
(private mode) for me.

My graphics card is reported as "llvmpipe (LLVM 11.0.0, 256 bits)" by
GNOME.

Vivien

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

bug#52375: Both pages load fine for me

[Jack Hill]

On Mon, 13 Dec 2021, Vivien Kraus via Bug reports for GNU Guix wrote:

> Dear guix,
>
> As a guix home user on a GNOME guix system, both pages work in epiphany
> (private mode) for me.

Interesting, thank for reporting. What is your `guix describe` output?
I've successfully recreated the problem on Sway, GNOME Wayland, and GNOME 
Xorg with

$ guix describe
Generation 47   Dec 15 2021 11:43:02    (current)
   guix 2a621f1
     repository URL: https://git.savannah.gnu.org/git/guix.git
     branch: master
     commit: 2a621f168faec09be7ed3f6b9351c24a472b19e4

Perhaps you have something else installed in your profile that I don't 
that the WebKitGTK browsers need to work?

Is anyone else able to reproduce this issue?

Best,
Jack

bug#52375: Both pages load fine for me

[Jack Hill]

[-- Attachment #1: Type: text/plain, Size: 242 bytes --]

I've attached the output of running `LD_DEBUG=all epiphany` and then 
demonstrating the problem. Unfortunately, I wasn't able to determine what 
part would be relevant, so I've attached the whole thing which is 1.3G 
uncompressed.

Best,
Jack

[-- Attachment #2: Type: application/x-xz, Size: 36516292 bytes --]

bug#52375: webkitgtk needs gst-plugins-bad

[Jack Hill]

I asked about this issue on #webkitgtk:gnome.org on IRC. It turns 
out that what's missing from my environment is gst-plugins-bad (most 
likely the fakevideosink plugin contained therein). If I install 
gst-plugins-bad into an environment with a webgkitgtk browser, the crash I 
was seeing is resolved. Only adding gst-plugins-bad to the inputs of 
webkitgtk doesn't seem to be enough to solve the problem. I suppose some 
additional wrapping is needed somewhere (although gst-plugins-base shows 
up in the webkitgtk references).

What's the best path forward here?

Should leaf applications that use webkitgtk be wrapped to find the right 
gst-plugins? This seems suboptimal to me. If the plugins are really 
dependencies of webkitgtk then perhaps they should be encoded that way in 
Guix.

Should webkitgtk be wrapped somehow to find the plugins on its own? How 
would this wrapping be done? Do we want to force all webkitgtk applications 
to carry around these dependencies?

Best,
Jack

bug#52375: webkitgtk page crashes on core-updates-frozen

[Maxim Cournoyer]

Hello Jack,

Jack Hill <jackhill@jackhill.us> writes:

> I asked about this issue on #webkitgtk:gnome.org on IRC. It turns out
> that what's missing from my environment is gst-plugins-bad (most
> likely the fakevideosink plugin contained therein). If I install 
> gst-plugins-bad into an environment with a webgkitgtk browser, the
> crash I was seeing is resolved. Only adding gst-plugins-bad to the
> inputs of webkitgtk doesn't seem to be enough to solve the problem. I
> suppose some additional wrapping is needed somewhere (although
> gst-plugins-base shows up in the webkitgtk references).
>
> What's the best path forward here?
>
> Should leaf applications that use webkitgtk be wrapped to find the
> right gst-plugins? This seems suboptimal to me. If the plugins are
> really dependencies of webkitgtk then perhaps they should be encoded
> that way in Guix.

I think upstream should improve their software to display more
informative messages when a plugin is missing to play some content (a
tab crash is not very helpful!) :-).

> Should webkitgtk be wrapped somehow to find the plugins on its own?
> How would this wrapping be done? Do we want to force all webkitgtk
> applications to carry around these dependencies?

I think there's not much to do here other than document the availability
of plugins to extend the capabilities of webkitgtk.  It's won't be
obvious to leaf package users though, so fixing it upstream would still
have value.

As discussed on #guix, some reasons for not propagating them or even
wrapping them is the fact that they are *plugins*, that is, they exist
in that form so that users can compose them for runtime discovery as
they see fit.  Propagating the plugins would go against this, and is not
very "Guixy" :-).

Another reason is that adding the gst-plugins-good and gst-plugins-bad
would inflate the size of the webkitgtk package by more than 1 GiB!
(compare "guix size webkitgtk" vs "guix size webkitgtk gst-plugins-good
gst-plugins-bad").

I'm tempted to make this change to the description of 'webkitgtk':

--8<---------------cut here---------------start------------->8---
modified   gnu/packages/webkit.scm
@@ -350,7 +350,9 @@ (define-public webkitgtk
     (description
      "WebKitGTK+ is a full-featured port of the WebKit rendering engine,
 suitable for projects requiring any kind of web integration, from hybrid
-HTML/CSS applications to full-fledged web browsers.")
+HTML/CSS applications to full-fledged web browsers.  WebKitGTK+ can play
+various video content through the use of the GStreamer plugins (not propagated
+by default) such as @code{gst-plugins-good} and @code{gst-plugins-bad}.")
     ;; WebKit's JavaScriptCore and WebCore components are available under
     ;; the GNU LGPL, while the rest is available under a BSD-style license.
     (license (list license:lgpl2.0
--8<---------------cut here---------------end--------------->8---

and close this as 'notabug'.  What do you think?

Thanks,

Maxim

bug#52375: webkitgtk page crashes on core-updates-frozen

[Leo Famulari]

On Tue, Dec 21, 2021 at 11:39:05AM -0500, Maxim Cournoyer wrote:
> Another reason is that adding the gst-plugins-good and gst-plugins-bad
> would inflate the size of the webkitgtk package by more than 1 GiB!
> (compare "guix size webkitgtk" vs "guix size webkitgtk gst-plugins-good
> gst-plugins-bad").

If there is a particular plugin that is actually required for some
package, we could use the gst-plugins/selection procedure to add the
dependency while hopefully increasing the closure size by less than 1
GiB.

bug#52375: webkitgtk page crashes on core-updates-frozen

[Jack Hill]

On Tue, 21 Dec 2021, Leo Famulari wrote:

> If there is a particular plugin that is actually required for some
> package, we could use the gst-plugins/selection procedure to add the
> dependency while hopefully increasing the closure size by less than 1
> GiB.

Leo,

Thanks for pointing this out, it turned out to be very helpful!

Best,
Jack

bug#52375: webkitgtk page crashes on core-updates-frozen

[Jack Hill]

On Tue, 21 Dec 2021, Maxim Cournoyer wrote:

> Hello Jack,
>
> Jack Hill <jackhill@jackhill.us> writes:
>
>> Should leaf applications that use webkitgtk be wrapped to find the
>> right gst-plugins? This seems suboptimal to me. If the plugins are
>> really dependencies of webkitgtk then perhaps they should be encoded
>> that way in Guix.
>
> I think upstream should improve their software to display more
> informative messages when a plugin is missing to play some content (a
> tab crash is not very helpful!) :-).

Indeed. There actually is an upstream issue for this: 
https://bugs.webkit.org/show_bug.cgi?id=233949

>> Should webkitgtk be wrapped somehow to find the plugins on its own?
>> How would this wrapping be done? Do we want to force all webkitgtk
>> applications to carry around these dependencies?
>
> I think there's not much to do here other than document the availability
> of plugins to extend the capabilities of webkitgtk.  It's won't be
> obvious to leaf package users though, so fixing it upstream would still
> have value.
>
> As discussed on #guix, some reasons for not propagating them or even
> wrapping them is the fact that they are *plugins*, that is, they exist
> in that form so that users can compose them for runtime discovery as
> they see fit.  Propagating the plugins would go against this, and is not
> very "Guixy" :-).
>
> Another reason is that adding the gst-plugins-good and gst-plugins-bad
> would inflate the size of the webkitgtk package by more than 1 GiB!
> (compare "guix size webkitgtk" vs "guix size webkitgtk gst-plugins-good
> gst-plugins-bad").
>
> I'm tempted to make this change to the description of 'webkitgtk':
>
> --8<---------------cut here---------------start------------->8---
> modified   gnu/packages/webkit.scm
> @@ -350,7 +350,9 @@ (define-public webkitgtk
>     (description
>      "WebKitGTK+ is a full-featured port of the WebKit rendering engine,
> suitable for projects requiring any kind of web integration, from hybrid
> -HTML/CSS applications to full-fledged web browsers.")
> +HTML/CSS applications to full-fledged web browsers.  WebKitGTK+ can play
> +various video content through the use of the GStreamer plugins (not propagated
> +by default) such as @code{gst-plugins-good} and @code{gst-plugins-bad}.")
>     ;; WebKit's JavaScriptCore and WebCore components are available under
>     ;; the GNU LGPL, while the rest is available under a BSD-style license.
>     (license (list license:lgpl2.0
> --8<---------------cut here---------------end--------------->8---
>
> and close this as 'notabug'.  What do you think?

I think that this would good to add as a hint to WebKitGTK users. However, 
I don't agree that it is notabug because I think browsers should work on 
commonly encountered web content out of the box without asking folks to 
track down the needed dependencies. I've opened a thread on 
guix-devel@gnu.org to solicit more thoughts/discussion on how to best 
address this issue: https://lists.gnu.org/archive/html/guix-devel/2021-12/msg00228.html

Thanks for helping think and work through this issue!
Jack

bug#52375: webkitgtk needs gst-plugins-bad

[Jack Hill]

On Tue, 21 Dec 2021, Jack Hill wrote:

> I asked about this issue on #webkitgtk:gnome.org on IRC. It turns out that 
> what's missing from my environment is gst-plugins-bad (most likely the 
> fakevideosink plugin contained therein). If I install gst-plugins-bad into an 
> environment with a webgkitgtk browser, the crash I was seeing is resolved. 
> Only adding gst-plugins-bad to the inputs of webkitgtk doesn't seem to be 
> enough to solve the problem. I suppose some additional wrapping is needed 
> somewhere (although gst-plugins-base shows up in the webkitgtk references).
>
> What's the best path forward here?

I got permission to quote from the IRC conversation for some additional 
context:

10:52 < jackhill> Hi folks! In the Guix WebKitGTK packages we seem to have introduced a problem that causes tabs to crash on some
                   pages. I'm trying to track it down, but could use a hand in either identifying the solution or in more
                   troubleshooting techniques: https://issues.guix.gnu.org/52375
10:55 < MichaelCatanzaro[m]> jackhill: Looks like you're missing a GStreamer element that is required (do you have:
                              gst-plugins-base, gst-plugins-good, and at least the free half of gst-plugins-bad?)
10:56 < MichaelCatanzaro[m]> Alternatively, maybe try deleting ~/.cache/gstreamer-1.0 in the off chance your registry is corrupt
10:58 < MichaelCatanzaro[m]> jackhill: I think you're missing the fakevideosink element from gst-plugins-bad
11:01 < jackhill> MichaelCatanzaro[m]: thanks. Looking at our package definition we only depend directlyon gst-plugins-base. It
                   seems that we were scared off of -bad at some point in the past:
                   https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/webkit.scm#n255
11:03 < jackhill> I'll look into adding them (and manybe clearing my cache). Were we wrong in our assesment of -bad?
11:06 < MichaelCatanzaro[m]> jackhill: Yup, that is mandatory... and disabling GStreamerGL is not recommended either
11:06 < jackhill> MichaelCatanzaro[m]: yep, adding -bad did it! Is there an official WebKitGTK statement that I can point to when
                   proposing my fix to Guix?
11:06 < MichaelCatanzaro[m]> Not all the elements are mandatory, but some are...
11:07 < MichaelCatanzaro[m]> jackhill: No, we just expect you to have a working gstreamer installation
11:07 < jackhill> hehe, fair enough
11:08 < MichaelCatanzaro[m]> Looks like there is a bug report: https://bugs.webkit.org/show_bug.cgi?id=233949
[daychange]
10:55 < jackhill> MichaelCatanzaro[m]: we're having a conversation in #guix:libera.chat about adding the gst-plugins-bad. Can I
                   quote our conversation yesterday to hopefully bring others up to speed?
11:26 < MichaelCatanzaro[m]> <jackhill> "Michael Catanzaro: we're..." <- Of course, all the history here is public anyway
11:27 < MichaelCatanzaro[m]> You need: gst-plugins-base, gst-plugins-good, and gst-plugins-bad (not gst-plugins-ugly)
11:27 < MichaelCatanzaro[m]> gst-libav especially welcome if available, but not required...
11:29 < MichaelCatanzaro[m]> GStreamer is indeed used inside the bwrap sandbox (most applications do not enable the sandbox, but
                              Ephy does)
11:29 < MichaelCatanzaro[m]> All web content is handled sandboxed :)

> Should leaf applications that use webkitgtk be wrapped to find the right 
> gst-plugins? This seems suboptimal to me. If the plugins are really 
> dependencies of webkitgtk then perhaps they should be encoded that way in 
> Guix.
>
> Should webkitgtk be wrapped somehow to find the plugins on its own? How would 
> this wrapping be done? Do we want to force all webkitgtk applications to 
> carry around these dependencies?

We talked through some of these option on #guix:libera.chat (thanks 
apteryx and cybersyn!) and it sounds like we're leaning towards the first 
option. An additional concern with webkitgtk always pulling in the plugins 
is that it increases the webkitgtk closure size by over 1G!

We're still waiting on webkitgtk builds to finish to help us determine if 
we can enable GSTREAMER_GL.

Best,
Jack