Bug 236144 – [GTK][WPE] Crash at WebKit::bindA11y() in WebKitGTK 2.35.2

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Christopher Davis]

This is reproducible with the latest checkout of GNOME OS devel with host epiphany. The app does not launch, crashing with the following backtrace:

Thread 1 "epiphany" received signal SIGSEGV, Segmentation fault.
0x00007ffff70c0735 in __strlen_avx2 () from /usr/lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x00007ffff70c0735 in __strlen_avx2 ()
    at /usr/lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff3a140e9 in WebKit::bindA11y(WTF::Vector<WTF::CString, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>&) ()
    at /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
#2  0x00007ffff3a130e8 in WebKit::bubblewrapSpawn(_GSubprocessLauncher*, WebKit::ProcessLauncher::LaunchOptions const&, char**, _GError**) ()
    at /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
#3  0x00007ffff3a15d44 in WebKit::ProcessLauncher::launchProcess() ()
    at /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
#4  0x00007ffff3885652 in WebKit::AuxiliaryProcessProxy::connect() ()
    at /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
#5  0x00007ffff391f24d in WebKit::WebProcessProxy::create(WebKit::WebProcessPool&, WebKit::WebsiteDataStore*, WebKit::WebProcessProxy::CaptivePortalMode, WebKit::WebProcessProxy::IsPrewarmed, WebCore::CrossOriginMode, WebKit::WebProcessProxy::ShouldLaunchProcess) () at /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
#6  0x00007ffff391f295 in WebKit::WebProcessPool::createNewWebProcess(WebKit::WebsiteDataStore*, WebKit::WebProcessProxy::CaptivePortalMode, WebKit::WebProcessProxy::IsPrewarmed, WebCore::CrossOriginMode) ()
    at /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
#7  0x00007ffff391d0f1 in WebKit::WebProcessPool::processForRegistrableDomain(WebKit::WebsiteDataStore&, WebCore::RegistrableDomain const&, WebKit::WebProcessProxy::CaptivePortalMode) () at /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
--Type <RET> for more, q to quit, c to continue without paging--c
#8  0x00007ffff391d325 in WebKit::WebPageProxy::launchProcess(WebCore::RegistrableDomain const&, WebKit::WebPageProxy::ProcessLaunchReason) () at /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
#9  0x00007ffff3922627 in WebKit::WebPageProxy::loadAlternateHTML(WTF::Span<unsigned char const, 18446744073709551615ul> const&, WTF::String const&, WTF::URL const&, WTF::URL const&, API::Object*) () at /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
#10 0x00007ffff39c178f in webkit_web_view_load_alternate_html () at /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
#11 0x00007ffff7f719dc in ephy_web_view_set_placeholder () at /usr/lib/x86_64-linux-gnu/epiphany/libephymain.so
#12 0x00007ffff7f2bf1d in session_start_element () at /usr/lib/x86_64-linux-gnu/epiphany/libephymain.so
#13 0x00007ffff72f7b8b in emit_start_element () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x00007ffff72f8ff3 in g_markup_parse_context_parse () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#15 0x00007ffff7f2d6a8 in load_stream_read_cb () at /usr/lib/x86_64-linux-gnu/epiphany/libephymain.so
#16 0x00007ffff74c61ad in async_ready_callback_wrapper () at /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#17 0x00007ffff74fee13 in g_task_return_now () at /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#18 0x00007ffff74fee66 in complete_in_idle_cb () at /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#19 0x00007ffff72f3c6b in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#20 0x00007ffff72f4178 in g_main_context_iterate.constprop () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#21 0x00007ffff72f4244 in g_main_context_iteration () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#22 0x00007ffff753132d in g_application_run () at /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#23 0x000055555555908f in main ()

[Alice Mikhaylenko]

I can reproduce it as well, and speciically only outside flatpak.

[Michael Catanzaro]

This file hasn't changed since 2.35.1. Line numbers would help a lot. That said, I guess it's coming from here:

proxy.setAddress(a11yAddress.get(), DBusAddressType::Abstract);

What happens when you run:

$ gdbus call --session --dest org.a11y.Bus --object-path /org/a11y/bus --method org.a11y.Bus.GetAddress

It must be returning something bogus? Of course, we should still not crash on unexpected data.

(In reply to Alexander Mikhaylenko from comment #1)
> I can reproduce it as well, and speciically only outside flatpak.

This code doesn't run under flatpak.

[Christopher Davis]

I get this:

```
❯ gdbus call --session --dest org.a11y.Bus --object-path /org/a11y/bus --method org.a11y.Bus.GetAddress
('unix:path=/run/user/1000/at-spi/bus,guid=f7309d02da6d9c749e996c0061fd67a8',)
```

[Michael Catanzaro]

Dunno then.

Sadly, I don't think we have debuginfo for WebKit in GNOME OS, so... hard to do more.

[Carlos Garcia Campos]

The problem is that the atspi address is no longer an abstract socket and we are assuming it is. I think atspi can use both now, but I'm now sure what it depends on. I'm not sure why we try to extract the path from the original socket address but the path is not actually used later for the a11y socket. Note that a11y is also broken in 2.34 with ATK when sandbox is enabled, but there's no crash there. I know how to fix the crash, but not how to make a11y work again with the sandbox enabled.

[Michael Catanzaro]

(In reply to Carlos Garcia Campos from comment #5)
> The problem is that the atspi address is no longer an abstract socket and we
> are assuming it is. I think atspi can use both now, but I'm now sure what it
> depends on. 

It should always be a filesystem socket now, since https://gitlab.gnome.org/GNOME/at-spi2-core/-/issues/43.

> I'm not sure why we try to extract the path from the original
> socket address but the path is not actually used later for the a11y socket.
> Note that a11y is also broken in 2.34 with ATK when sandbox is enabled, but
> there's no crash there. I know how to fix the crash, but not how to make
> a11y work again with the sandbox enabled.

It has *never* worked for me, see bug #227640.

[Michael Catanzaro]

Can we change XDGDBusProxyLauncher::dbusAddressToPath to search for both "abstract=" and "path=", and remove the DBusAddressType parameter?

[Carlos Garcia Campos]

(In reply to Michael Catanzaro from comment #6)
> (In reply to Carlos Garcia Campos from comment #5)
> > The problem is that the atspi address is no longer an abstract socket and we
> > are assuming it is. I think atspi can use both now, but I'm now sure what it
> > depends on. 
> 
> It should always be a filesystem socket now, since
> https://gitlab.gnome.org/GNOME/at-spi2-core/-/issues/43.

See also https://gitlab.gnome.org/GNOME/at-spi2-core/-/blob/master/bus/at-spi-bus-launcher.c#L501

> > I'm not sure why we try to extract the path from the original
> > socket address but the path is not actually used later for the a11y socket.
> > Note that a11y is also broken in 2.34 with ATK when sandbox is enabled, but
> > there's no crash there. I know how to fix the crash, but not how to make
> > a11y work again with the sandbox enabled.
> 
> It has *never* worked for me, see bug #227640.

It worked for me with both ATK and ATSPI.

[Carlos Garcia Campos]

(In reply to Michael Catanzaro from comment #7)
> Can we change XDGDBusProxyLauncher::dbusAddressToPath to search for both
> "abstract=" and "path=", and remove the DBusAddressType parameter?

I tried that, and it indeed fixes the crash, but a11y is still broken because xdg-dbus-proxy fails to connect to the a11y original bus address for some reason. Note that in the case of a11y we don't really use the path, even when it's required to launch the proxy.

[Carlos Garcia Campos]

Ok, I've found the problem. We are exposing the socket to the web process, which is right, but we don't expose the original socket to the xdg-dbus-proxy and it fails to connect to it, because the path doesn't exist.

[Carlos Garcia Campos]

Created attachment 451234 [details]
Patch

[Adrian Perez]

Comment on attachment 451234 [details]
Patch

I also liked it that the patch brings some siplification along with the fix =)

[EWS]

Committed r289369 (246957@main): <https://commits.webkit.org/246957@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 451234 [details].

[Michael Catanzaro]

(In reply to Carlos Garcia Campos from comment #10)
> Ok, I've found the problem. We are exposing the socket to the web process,
> which is right, but we don't expose the original socket to the
> xdg-dbus-proxy and it fails to connect to it, because the path doesn't exist.

Ah, so it's my fault then. Probably broke in r272882.