Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1012746: libwebkit2gtk-4.0-37: 2.36.3-1~deb11u1 fails messily over glx
66 views
Skip to first unread message
Markus Demleitner
Jun 13, 2022, 4:50:04 AM6/13/22
to
Package: libwebkit2gtk-4.0-37
Version: 2.36.3-1~deb11u1
Severity: normal
X-Debbugs-Cc: te...@security.debian.org
Dear Maintainer,
After the update to 2.36.3-1~deb11u1, webkit-using clients like luakit
or midori do not work any more through ssh-forwarded X connections (as in
ssh -X <host> luakit). The clients emit messages like:
(WebKitWebProcess:8867): Gdk-ERROR **: 10:24:22.799: The program 'WebKitWebProcess' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
(Details: serial 220 error_code 8 request_code 151 (GLX) minor_code 34)
[plus the lecture on going sync to get backtraces, which I'll happily do
if there's any problem reproducing this] repeated a couple of times per second,
whereas in the syslog, one gets messages like:
traps: eadedCompositor[8752] trap int3 ip:f3b7315b sp:e9dfe480 error:0 in libglib-2.0.so.0.6600.8[f3b33000+8b000]
again at a few Hertz, where the number in square brackets (the PID, I guess)
quickly counts up.
Downgrading to 2.34.6-1~deb11u1 fixes things.
In both luakit and midori, the visible effect is that no webpage is displayed
(but the clients' UIs are properly drawn).
-- System Information:
Debian Release: 11.3
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable'), (500, 'oldstable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64
Kernel: Linux 4.19.0-16-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages libwebkit2gtk-4.0-37 depends on:
ii bubblewrap 0.4.1-3
ii gstreamer1.0-plugins-base 1.18.4-2
ii gstreamer1.0-plugins-good 1.18.4-2
ii libatk1.0-0 2.36.0-2
ii libc6 2.31-13+deb11u3
ii libcairo2 1.16.0-5
ii libegl1 1.3.2-1
ii libelogind0 [libsystemd0] 246.9.1-1+debian1
ii libenchant-2-2 2.2.15-1
ii libfontconfig1 2.13.1-4.2
ii libfreetype6 2.10.4+dfsg-1
ii libgcc-s1 10.2.1-6
ii libgcrypt20 1.8.7-6
ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1
ii libglib2.0-0 2.66.8-1
ii libglx0 1.3.2-1
ii libgstreamer-gl1.0-0 1.18.4-2
ii libgstreamer-plugins-base1.0-0 1.18.4-2
ii libgstreamer1.0-0 1.18.4-2.1
ii libgtk-3-0 3.24.24-4+deb11u2
ii libharfbuzz-icu0 2.7.4-1
ii libharfbuzz0b 2.7.4-1
ii libhyphen0 2.8.8-7
ii libicu67 67.1-7
ii libjavascriptcoregtk-4.0-18 2.36.3-1~deb11u1
ii libjpeg62-turbo 1:2.0.6-4
ii liblcms2-2 2.12~rc1-2
ii libmanette-0.2-0 0.2.5-1
ii libnotify4 0.7.9-3
ii libopengl0 1.3.2-1
ii libopenjp2-7 2.4.0-3
ii libpango-1.0-0 1.46.2-3
ii libpng16-16 1.6.37-3
ii libseccomp2 2.5.1-1+deb11u1
ii libsecret-1-0 0.20.4-2
ii libsoup2.4-1 2.72.0-2
ii libsqlite3-0 3.34.1-3
ii libstdc++6 10.2.1-6
ii libtasn1-6 4.16.0-2
ii libwayland-client0 1.18.0-2~exp1.1
ii libwayland-egl1 1.18.0-2~exp1.1
ii libwayland-server0 1.18.0-2~exp1.1
ii libwebp6 0.6.1-2.1
ii libwebpdemux2 0.6.1-2.1
ii libwoff1 1.0.2-1+b1
ii libwpe-1.0-1 1.10.0-2
ii libwpebackend-fdo-1.0-1 1.8.0-1
ii libx11-6 2:1.7.2-1
ii libxcomposite1 1:0.4.5-1
ii libxdamage1 1:1.1.5-2
ii libxml2 2.9.10+dfsg-6.7+deb11u2
ii libxslt1.1 1.1.34-4
ii xdg-dbus-proxy 0.1.2-2
ii zlib1g 1:1.2.11.dfsg-2+deb11u1
Versions of packages libwebkit2gtk-4.0-37 recommends:
pn gstreamer1.0-gl <none>
pn gstreamer1.0-libav <none>
pn gstreamer1.0-plugins-bad <none>
ii libgl1-mesa-dri 20.3.5-1
ii xdg-desktop-portal-gtk 1.8.0-1
Versions of packages libwebkit2gtk-4.0-37 suggests:
pn gstreamer1.0-alsa <none>
-- no debconf information
Version: 2.36.3-1~deb11u1
Severity: normal
X-Debbugs-Cc: te...@security.debian.org
Dear Maintainer,
After the update to 2.36.3-1~deb11u1, webkit-using clients like luakit
or midori do not work any more through ssh-forwarded X connections (as in
ssh -X <host> luakit). The clients emit messages like:
(WebKitWebProcess:8867): Gdk-ERROR **: 10:24:22.799: The program 'WebKitWebProcess' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
(Details: serial 220 error_code 8 request_code 151 (GLX) minor_code 34)
[plus the lecture on going sync to get backtraces, which I'll happily do
if there's any problem reproducing this] repeated a couple of times per second,
whereas in the syslog, one gets messages like:
traps: eadedCompositor[8752] trap int3 ip:f3b7315b sp:e9dfe480 error:0 in libglib-2.0.so.0.6600.8[f3b33000+8b000]
again at a few Hertz, where the number in square brackets (the PID, I guess)
quickly counts up.
Downgrading to 2.34.6-1~deb11u1 fixes things.
In both luakit and midori, the visible effect is that no webpage is displayed
(but the clients' UIs are properly drawn).
-- System Information:
Debian Release: 11.3
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable'), (500, 'oldstable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64
Kernel: Linux 4.19.0-16-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages libwebkit2gtk-4.0-37 depends on:
ii bubblewrap 0.4.1-3
ii gstreamer1.0-plugins-base 1.18.4-2
ii gstreamer1.0-plugins-good 1.18.4-2
ii libatk1.0-0 2.36.0-2
ii libc6 2.31-13+deb11u3
ii libcairo2 1.16.0-5
ii libegl1 1.3.2-1
ii libelogind0 [libsystemd0] 246.9.1-1+debian1
ii libenchant-2-2 2.2.15-1
ii libfontconfig1 2.13.1-4.2
ii libfreetype6 2.10.4+dfsg-1
ii libgcc-s1 10.2.1-6
ii libgcrypt20 1.8.7-6
ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1
ii libglib2.0-0 2.66.8-1
ii libglx0 1.3.2-1
ii libgstreamer-gl1.0-0 1.18.4-2
ii libgstreamer-plugins-base1.0-0 1.18.4-2
ii libgstreamer1.0-0 1.18.4-2.1
ii libgtk-3-0 3.24.24-4+deb11u2
ii libharfbuzz-icu0 2.7.4-1
ii libharfbuzz0b 2.7.4-1
ii libhyphen0 2.8.8-7
ii libicu67 67.1-7
ii libjavascriptcoregtk-4.0-18 2.36.3-1~deb11u1
ii libjpeg62-turbo 1:2.0.6-4
ii liblcms2-2 2.12~rc1-2
ii libmanette-0.2-0 0.2.5-1
ii libnotify4 0.7.9-3
ii libopengl0 1.3.2-1
ii libopenjp2-7 2.4.0-3
ii libpango-1.0-0 1.46.2-3
ii libpng16-16 1.6.37-3
ii libseccomp2 2.5.1-1+deb11u1
ii libsecret-1-0 0.20.4-2
ii libsoup2.4-1 2.72.0-2
ii libsqlite3-0 3.34.1-3
ii libstdc++6 10.2.1-6
ii libtasn1-6 4.16.0-2
ii libwayland-client0 1.18.0-2~exp1.1
ii libwayland-egl1 1.18.0-2~exp1.1
ii libwayland-server0 1.18.0-2~exp1.1
ii libwebp6 0.6.1-2.1
ii libwebpdemux2 0.6.1-2.1
ii libwoff1 1.0.2-1+b1
ii libwpe-1.0-1 1.10.0-2
ii libwpebackend-fdo-1.0-1 1.8.0-1
ii libx11-6 2:1.7.2-1
ii libxcomposite1 1:0.4.5-1
ii libxdamage1 1:1.1.5-2
ii libxml2 2.9.10+dfsg-6.7+deb11u2
ii libxslt1.1 1.1.34-4
ii xdg-dbus-proxy 0.1.2-2
ii zlib1g 1:1.2.11.dfsg-2+deb11u1
Versions of packages libwebkit2gtk-4.0-37 recommends:
pn gstreamer1.0-gl <none>
pn gstreamer1.0-libav <none>
pn gstreamer1.0-plugins-bad <none>
ii libgl1-mesa-dri 20.3.5-1
ii xdg-desktop-portal-gtk 1.8.0-1
Versions of packages libwebkit2gtk-4.0-37 suggests:
pn gstreamer1.0-alsa <none>
-- no debconf information
Alberto Garcia
Jun 14, 2022, 9:40:05 AM6/14/22
to
On Mon, Jun 13, 2022 at 10:32:59AM +0200, Markus Demleitner wrote:
> After the update to 2.36.3-1~deb11u1, webkit-using clients like
> luakit or midori do not work any more through ssh-forwarded X
> connections (as in ssh -X <host> luakit).
I gave this a quick try using a VM and I can open luakit and midori
> After the update to 2.36.3-1~deb11u1, webkit-using clients like
> luakit or midori do not work any more through ssh-forwarded X
> connections (as in ssh -X <host> luakit).
just fine, with both WebKit versions... I'll try to see if I can
reproduce this on a different computer.
Berto
Markus Demleitner
Jun 21, 2022, 6:00:04 AM6/21/22
to
On Tue, Jun 14, 2022 at 01:33:34PM +0000, Alberto Garcia wrote:
> I gave this a quick try using a VM and I can open luakit and midori
> just fine, with both WebKit versions... I'll try to see if I can
> reproduce this on a different computer.
Well, given that I just tried to get a trackback and discovered
> I gave this a quick try using a VM and I can open luakit and midori
> just fine, with both WebKit versions... I'll try to see if I can
> reproduce this on a different computer.
that's harder than just following the advice and running
ssh -tX <host> env GDK_SYNCHRONIZE=1 gdb luakit
and breaking on gdk_x_error; I figure it's because that breakpoint is
never reached in the UI process, only in the WebKitWebProcess.
A quick web search hasn't brought up quick advice on how to debug
things in there -- is there a quick howto somewhere?
Thanks,
Markus
Alberto Garcia
Jun 21, 2022, 7:00:03 AM6/21/22
to
On Tue, Jun 21, 2022 at 11:40:49AM +0200, Markus Demleitner wrote:
> Well, given that I just tried to get a trackback and discovered
> that's harder than just following the advice and running
>
> ssh -tX <host> env GDK_SYNCHRONIZE=1 gdb luakit
>
> and breaking on gdk_x_error; I figure it's because that breakpoint is
> never reached in the UI process, only in the WebKitWebProcess.
> A quick web search hasn't brought up quick advice on how to debug
> things in there -- is there a quick howto somewhere?
If the web process crashes and you have the systemd-coredump package
> Well, given that I just tried to get a trackback and discovered
> that's harder than just following the advice and running
>
> ssh -tX <host> env GDK_SYNCHRONIZE=1 gdb luakit
>
> and breaking on gdk_x_error; I figure it's because that breakpoint is
> never reached in the UI process, only in the WebKitWebProcess.
> A quick web search hasn't brought up quick advice on how to debug
> things in there -- is there a quick howto somewhere?
you should be able to see the core dump with coredumpctl.
It not you can connect gdb to a running WebProcess with 'gdb -p PID'
Berto
Markus Demleitner
Jun 21, 2022, 10:50:03 AM6/21/22
to
On Tue, Jun 21, 2022 at 10:46:53AM +0000, Alberto Garcia wrote:
> If the web process crashes and you have the systemd-coredump package
> you should be able to see the core dump with coredumpctl.
Oh, right: WebKitWebProcess does indeed coredump once I ulimit -c
> If the web process crashes and you have the systemd-coredump package
> you should be able to see the core dump with coredumpctl.
unlimited. Here's a dump (I've not pulled the dbgsyms for GLX, X11,
gdk, and glib, hoping they're irrelevant for the problem at hand):
#0 0xf3b1d15b in g_log_writer_default ()
from /usr/lib/i386-linux-gnu/libglib-2.0.so.0
#1 0xf3b1b2d8 in g_log_structured_array ()
from /usr/lib/i386-linux-gnu/libglib-2.0.so.0
#2 0xf3b1bcc9 in g_log_structured_standard ()
from /usr/lib/i386-linux-gnu/libglib-2.0.so.0
#3 0xf1eac916 in ?? () from /usr/lib/i386-linux-gnu/libgdk-3.so.0
#4 0xf1eb9fb4 in ?? () from /usr/lib/i386-linux-gnu/libgdk-3.so.0
#5 0xf0c5b208 in _XError () from /usr/lib/i386-linux-gnu/libX11.so.6
#6 0xeae96c62 in ?? () from /usr/lib/i386-linux-gnu/libGLX_mesa.so.0
#7 0xeae8fac8 in ?? () from /usr/lib/i386-linux-gnu/libGLX_mesa.so.0
#8 0xf17b1e24 in ?? () from /usr/lib/i386-linux-gnu/libGLX.so.0
#9 0xf6420528 in createGLXARBContext ()
at ../Source/WebCore/platform/graphics/glx/GLContextGLX.cpp:109
#10 0xf6421fdf in WebCore::GLContextGLX::createWindowContext ()
at ../Source/WebCore/platform/graphics/glx/GLContextGLX.cpp:195
#11 0xf6423f5b in WebCore::GLContextGLX::createContext ()
at ../Source/WebCore/platform/graphics/glx/GLContextGLX.cpp:280
#12 0xf63d49b7 in WebCore::GLContext::createContextForWindow ()
at ../Source/WebCore/platform/graphics/GLContext.cpp:97
#13 0xf478b73b in WebKit::ThreadedCompositor::createGLContext ()
at ../Source/WebKit/Shared/CoordinatedGraphics/threadedcompositor/ThreadedCompositor.cpp:96
--Type <RET> for more, q to quit, c to continue without paging--
#14 0xf478b86f in operator() ()
at ../Source/WebKit/Shared/CoordinatedGraphics/threadedcompositor/ThreadedCompositor.cpp:73
#15 call () at WTF/Headers/wtf/Function.h:53
#16 0xf4789bc7 in WTF::Function<void ()>::operator()() const ()
at WTF/Headers/wtf/Function.h:82
#17 operator() ()
at ../Source/WebKit/Shared/CoordinatedGraphics/threadedcompositor/CompositingRunLoop.cpp:90
#18 call () at WTF/Headers/wtf/Function.h:53
#19 0xf36f845f in ?? ()
from /usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18
#20 0xf37588e8 in ?? ()
from /usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18
#21 0xf375941c in ?? ()
from /usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18
#22 0xf3b147a4 in g_main_context_dispatch ()
from /usr/lib/i386-linux-gnu/libglib-2.0.so.0
#23 0xf3b14b69 in ?? () from /usr/lib/i386-linux-gnu/libglib-2.0.so.0
#24 0xf3b14ec1 in g_main_loop_run ()
from /usr/lib/i386-linux-gnu/libglib-2.0.so.0
#25 0xf3759581 in WTF::RunLoop::run() ()
from /usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18
#26 0xf478860c in operator() ()
at ../Source/WebKit/Shared/CoordinatedGraphics/threadedcompositor/CompositingRunLoop.cpp:49
#27 call () at WTF/Headers/wtf/Function.h:53
#28 0xf36fad99 in ?? ()
from /usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18
#29 0xf375c0c8 in ?? ()
from /usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18
#30 0xf088b0b4 in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#31 0xf3feb296 in clone () from /lib/i386-linux-gnu/libc.so.6
Thanks,
Markus
Markus Demleitner
Aug 18, 2022, 4:20:04 AM8/18/22
to
When 2.34.6-1~deb11 came along on Aug 16, I had great hopes it might
accidentally fix this, too -- but alas, it didn't.
accidentally fix this, too -- but alas, it didn't.
Markus Demleitner
Aug 30, 2022, 5:50:04 AM8/30/22
to
Given the publicity of some recent webkit bugs I start getting mildly
nervous about the outdated webkit on my box. After the latest update
didn't improve things, I started poking a bit more, and it turns out
that the bug title was *very much* over-generalising.
The crashes very specifically occur on one screen of a two-screen
"ZaphodHeads" setup on nouveau. It is actually the case that
DISPLAY=display-host:0.0 luakit
runs just fine, whereas
DISPLAY=display-host:0.1 luakit
shows the crashes.
I have to admit this badly stumps me.
I'm still reluctant to delve into either of webkit or nouveau, so...
does someone perhaps have a theory what might possibly cause such a
thing that I could try before I start digging?
nervous about the outdated webkit on my box. After the latest update
didn't improve things, I started poking a bit more, and it turns out
that the bug title was *very much* over-generalising.
The crashes very specifically occur on one screen of a two-screen
"ZaphodHeads" setup on nouveau. It is actually the case that
DISPLAY=display-host:0.0 luakit
runs just fine, whereas
DISPLAY=display-host:0.1 luakit
shows the crashes.
I have to admit this badly stumps me.
I'm still reluctant to delve into either of webkit or nouveau, so...
does someone perhaps have a theory what might possibly cause such a
thing that I could try before I start digging?
Markus Demleitner
Jul 31, 2023, 7:40:05 AM7/31/23
to
With bookworm, things have significantly changed; it seems webkit2gtk
is now pretty much broken on non-local displays, but then the
crashes are somewhat milder.
I believe the easiest webkit client to investigate the problem in is
surf, where the raw symptom is:
$ ssh -X <somehost> surf http://www.debian.org
libEGL warning: DRI2: failed to authenticate
(WebKitWebProcess:498): Gdk-WARNING **: 13:11:26.540: The program 'WebKitWebProcess' received an X Window System error.
(Details: serial 173 error_code 1 request_code 154 (unknown) minor_code 1)
(Note to programmers: [...])
web process terminated: crashed
Regrettably, this time I can't get the WebKitWebProcess to dump core
-- is there a simple knob to make it do that on a X error? As
usual, the things die faster than you could attach to them.
On the plus side, it seems the crashes are now a fairly solid feature
that I'm seeing independent of particular screens on particular
graphics cards.
Oh, and, Good News: with WEBKIT_DISABLE_COMPOSITING_MODE=1 things are
just fine:
$ ssh -X <somehost> env WEBKIT_DISABLE_COMPOSITING_MODE=1 surf http://www.debian.org
works in every combination I've tried. If you say "live with
disabling compositing mode" I suppose I could live with closing this
bug.
is now pretty much broken on non-local displays, but then the
crashes are somewhat milder.
I believe the easiest webkit client to investigate the problem in is
surf, where the raw symptom is:
$ ssh -X <somehost> surf http://www.debian.org
libEGL warning: DRI2: failed to authenticate
(WebKitWebProcess:498): Gdk-WARNING **: 13:11:26.540: The program 'WebKitWebProcess' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadRequest (invalid request code or no such operation)'.
(Details: serial 173 error_code 1 request_code 154 (unknown) minor_code 1)
(Note to programmers: [...])
web process terminated: crashed
Regrettably, this time I can't get the WebKitWebProcess to dump core
-- is there a simple knob to make it do that on a X error? As
usual, the things die faster than you could attach to them.
On the plus side, it seems the crashes are now a fairly solid feature
that I'm seeing independent of particular screens on particular
graphics cards.
Oh, and, Good News: with WEBKIT_DISABLE_COMPOSITING_MODE=1 things are
just fine:
$ ssh -X <somehost> env WEBKIT_DISABLE_COMPOSITING_MODE=1 surf http://www.debian.org
works in every combination I've tried. If you say "live with
disabling compositing mode" I suppose I could live with closing this
bug.
Alberto Garcia
Sep 13, 2023, 11:00:04 AM9/13/23
to
On Mon, Jul 31, 2023 at 01:22:43PM +0200, Markus Demleitner wrote:
> With bookworm, things have significantly changed; it seems webkit2gtk
> is now pretty much broken on non-local displays, but then the
> crashes are somewhat milder.
>
> I believe the easiest webkit client to investigate the problem in is
> surf, where the raw symptom is:
>
> $ ssh -X <somehost> surf http://www.debian.org
> libEGL warning: DRI2: failed to authenticate
Out of curiosity, can you try the same with the MiniBrowser instead of
> With bookworm, things have significantly changed; it seems webkit2gtk
> is now pretty much broken on non-local displays, but then the
> crashes are somewhat milder.
>
> I believe the easiest webkit client to investigate the problem in is
> surf, where the raw symptom is:
>
> $ ssh -X <somehost> surf http://www.debian.org
> libEGL warning: DRI2: failed to authenticate
surf?
/usr/lib/x86_64-linux-gnu/webkit*/MiniBrowser
Berto
0 new messages