Bug 199573 – [GTK] Next crashes when using D-Bus and hardware acceleration

• Status: RESOLVED
• Resolution: INVALID
• Component: WebKitGTK

I'm working on the WebKitGTK port of Next browser:
https://next.atlas.engineer.
(Mirror: https://github.com/atlas-engineer/next)

With commits
https://github.com/atlas-engineer/next/commit/17355a99414678313688cae5b24d17a881b60a15
and
https://github.com/atlas-engineer/next/commit/0dcb9217af64e18bff62a903a3f9383d4bc17d5b,
we've switch RPC system from XML-RPC to D-Bus.

Since then, starting Next with

  WEBKIT_DISABLE_COMPOSITING_MODE=1
  
crashes the WebKitGTK port.

Backtrace:

--8<---------------cut here---------------start------------->8---
(process:6928): Gtk-CRITICAL **: 15:33:42.485: _gtk_style_provider_private_get_settings:
assertion 'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed

Thread 1 "next-gtk-webkit" received signal SIGSEGV, Segmentation fault.
0x00007ffff50538b0 in _gtk_settings_get_screen ()
	 from /gnu/store/h6dmb84rn291nwny73x3wfa1anh8n32g-gtk+-3.24.8/lib/libgtk-3.so.0
(gdb) bt
#0  0x00007ffff50538b0 in _gtk_settings_get_screen ()
	 from /gnu/store/h6dmb84rn291nwny73x3wfa1anh8n32g-gtk+-3.24.8/lib/libgtk-3.so.0
#1  0x00007ffff4f0e704 in gtk_css_value_icon_theme_compute ()
	 from /gnu/store/h6dmb84rn291nwny73x3wfa1anh8n32g-gtk+-3.24.8/lib/libgtk-3.so.0
#2  0x00007ffff4f2ca74 in gtk_css_static_style_compute_value ()
	 from /gnu/store/h6dmb84rn291nwny73x3wfa1anh8n32g-gtk+-3.24.8/lib/libgtk-3.so.0
#3  0x00007ffff4f1948c in _gtk_css_lookup_resolve ()
	 from /gnu/store/h6dmb84rn291nwny73x3wfa1anh8n32g-gtk+-3.24.8/lib/libgtk-3.so.0
#4  0x00007ffff4f2c9b0 in gtk_css_static_style_new_compute ()
	 from /gnu/store/h6dmb84rn291nwny73x3wfa1anh8n32g-gtk+-3.24.8/lib/libgtk-3.so.0
#5  0x00007ffff4f2c9f5 in gtk_css_static_style_get_default ()
	 from /gnu/store/h6dmb84rn291nwny73x3wfa1anh8n32g-gtk+-3.24.8/lib/libgtk-3.so.0
#6  0x00007ffff4f19dc2 in gtk_css_node_init ()
	 from /gnu/store/h6dmb84rn291nwny73x3wfa1anh8n32g-gtk+-3.24.8/lib/libgtk-3.so.0
#7  0x00007ffff34eb537 in g_type_create_instance ()
	 from /gnu/store/0q9pq9flr76rh4bv2524niknknnl2kvq-glib-2.56.3/lib/libgobject-2.0.so.0
#8  0x00007ffff34cdb1b in g_object_new_internal ()
	 from /gnu/store/0q9pq9flr76rh4bv2524niknknnl2kvq-glib-2.56.3/lib/libgobject-2.0.so.0
#9  0x00007ffff34cefb2 in g_object_new_with_properties ()
	 from /gnu/store/0q9pq9flr76rh4bv2524niknknnl2kvq-glib-2.56.3/lib/libgobject-2.0.so.0
#10 0x00007ffff34cfba1 in g_object_new ()
	 from /gnu/store/0q9pq9flr76rh4bv2524niknknnl2kvq-glib-2.56.3/lib/libgobject-2.0.so.0
#11 0x00007ffff4f34aaa in gtk_css_widget_node_new ()
	 from /gnu/store/h6dmb84rn291nwny73x3wfa1anh8n32g-gtk+-3.24.8/lib/libgtk-3.so.0
#12 0x00007ffff50fca41 in gtk_widget_init ()
	 from /gnu/store/h6dmb84rn291nwny73x3wfa1anh8n32g-gtk+-3.24.8/lib/libgtk-3.so.0
#13 0x00007ffff34eb537 in g_type_create_instance ()
	 from /gnu/store/0q9pq9flr76rh4bv2524niknknnl2kvq-glib-2.56.3/lib/libgobject-2.0.so.0
#14 0x00007ffff34cdb1b in g_object_new_internal ()
	 from /gnu/store/0q9pq9flr76rh4bv2524niknknnl2kvq-glib-2.56.3/lib/libgobject-2.0.so.0
#15 0x00007ffff34cf8a8 in g_object_new_valist ()
	 from /gnu/store/0q9pq9flr76rh4bv2524niknknnl2kvq-glib-2.56.3/lib/libgobject-2.0.so.0
#16 0x00007ffff34cfb8c in g_object_new ()
	 from /gnu/store/0q9pq9flr76rh4bv2524niknknnl2kvq-glib-2.56.3/lib/libgobject-2.0.so.0
#17 0x00007ffff5cea106 in webkit_web_view_new_with_context ()
	 from
/gnu/store/y5n70n2ds04niwkifk1aw52l48y5s2ij-webkitgtk-2.24.2/lib/libwebkit2gtk-4.0.so.37
#18 0x0000000000405cb2 in minibuffer_init ()
#19 0x0000000000406e39 in window_init ()
#20 0x0000000000407590 in server_window_make ()
#21 0x0000000000408c31 in server_handler ()
#22 0x00007ffff49366dc in call_in_idle_cb ()
	 from /gnu/store/0q9pq9flr76rh4bv2524niknknnl2kvq-glib-2.56.3/lib/libgio-2.0.so.0
#23 0x00007ffff33eaa0a in g_main_context_dispatch ()
	 from /gnu/store/0q9pq9flr76rh4bv2524niknknnl2kvq-glib-2.56.3/lib/libglib-2.0.so.0
#24 0x00007ffff33ead98 in g_main_context_iterate.isra ()
	 from /gnu/store/0q9pq9flr76rh4bv2524niknknnl2kvq-glib-2.56.3/lib/libglib-2.0.so.0
#25 0x00007ffff33eb0b2 in g_main_loop_run ()
	 from /gnu/store/0q9pq9flr76rh4bv2524niknknnl2kvq-glib-2.56.3/lib/libglib-2.0.so.0
#26 0x00007ffff4fc8845 in gtk_main ()
	 from /gnu/store/h6dmb84rn291nwny73x3wfa1anh8n32g-gtk+-3.24.8/lib/libgtk-3.so.0
#27 0x0000000000408fe9 in main ()
--8<---------------cut here---------------end--------------->8---

Here is the content of minibuffer_init:

--8<---------------cut here---------------start------------->8---
Minibuffer *minibuffer_init() {
	Minibuffer *minibuffer = calloc(1, sizeof (Minibuffer));
	minibuffer->web_view = WEBKIT_WEB_VIEW(webkit_web_view_new());
	minibuffer->callback_count = 0;

	g_signal_connect(minibuffer->web_view, "web-process-crashed",
		G_CALLBACK(minibuffer_web_view_web_process_crashed), minibuffer);

	return minibuffer;
}
--8<---------------cut here---------------end--------------->8---

The aforementioned commits are rather substantial, so it's not obvious to see
what causes the issue (maybe D-Bus is a red herring).
But maybe someone here would have a good hunch?
Is there a link between D-Bus, WebKitGTK+ and hardware acceleration?

[Michael Catanzaro]

> Is there a link between D-Bus, WebKitGTK+ and hardware acceleration?

Of course not.

Does valgrind have anything to say? I know I suggested that you report this here, but looking at it again, I remember that inside GTK CSS code are almost always memory corruption, so I'm not confident this is actually WebKit's fault.

Normally I would insist that you install debuginfo and use 'bt full' to take the backtrace, but in this case I think a result from valgrind is more important since I have a suspicion it will point somewhere else. (Regardless, do make sure you have all appropriate debuginfo installed to get the best result possible out of valgrind.)

I also suspect a memory issue.  Valgrind reports lots of leaks, but so
do most GTK applications I think.  I'm not sure how to investigate the
relevant part with Valgrind, would you have some hints?

By "debuginfo", you mean compile webkitgtk with debug symbols on /
unstripped binaries?  Or is there a special flag?

[Michael Catanzaro]

(In reply to mail from comment #2)
> I also suspect a memory issue.  Valgrind reports lots of leaks, but so
> do most GTK applications I think.  I'm not sure how to investigate the
> relevant part with Valgrind, would you have some hints?

Well we're not interested in leaks. The goal is to see if it complains about something worse, like an invalid write, before it crashes.

> By "debuginfo", you mean compile webkitgtk with debug symbols on /
> unstripped binaries?  Or is there a special flag?

Of course. If you're building WebKit yourself, use -DCMAKE_BUILD_TYPE=RelWithDebInfo or -g. If you get it from a distro build, install the distro's debuginfo package. The backtrace should include line numbers and member variables. (Though again, in this case I suspect valgrind output will be more important.)

More valgrind investigation didn't reveal much:

```
==15710== Invalid read of size 8
==15710==    at 0x76608B0: _gtk_settings_get_screen (in /gnu/store/h6dmb84rn291nwny73x3wfa1anh8n32g-gtk+-3.24.8/lib/libgtk-3.so.0.2404.4)
==15710==    by 0x751B703: gtk_css_value_icon_theme_compute (in /gnu/store/h6dmb84rn291nwny73x3wfa1anh8n32g-gtk+-3.24.8/lib/libgtk-3.so.0.2404.4)
==15710==    by 0x7539A73: gtk_css_static_style_compute_value (in /gnu/store/h6dmb84rn291nwny73x3wfa1anh8n32g-gtk+-3.24.8/lib/libgtk-3.so.0.2404.4)
==15710==    by 0x752648B: _gtk_css_lookup_resolve (in /gnu/store/h6dmb84rn291nwny73x3wfa1anh8n32g-gtk+-3.24.8/lib/libgtk-3.so.0.2404.4)
==15710==    by 0x75399AF: gtk_css_static_style_new_compute (in /gnu/store/h6dmb84rn291nwny73x3wfa1anh8n32g-gtk+-3.24.8/lib/libgtk-3.so.0.2404.4)
==15710==    by 0x75399F4: gtk_css_static_style_get_default (in /gnu/store/h6dmb84rn291nwny73x3wfa1anh8n32g-gtk+-3.24.8/lib/libgtk-3.so.0.2404.4)
==15710==    by 0x7526DC1: gtk_css_node_init (in /gnu/store/h6dmb84rn291nwny73x3wfa1anh8n32g-gtk+-3.24.8/lib/libgtk-3.so.0.2404.4)
==15710==    by 0x933A536: g_type_create_instance (in /gnu/store/0q9pq9flr76rh4bv2524niknknnl2kvq-glib-2.56.3/lib/libgobject-2.0.so.0.5600.3)
==15710==    by 0x931CB1A: g_object_new_internal (in /gnu/store/0q9pq9flr76rh4bv2524niknknnl2kvq-glib-2.56.3/lib/libgobject-2.0.so.0.5600.3)
==15710==    by 0x931DFB1: g_object_new_with_properties (in /gnu/store/0q9pq9flr76rh4bv2524niknknnl2kvq-glib-2.56.3/lib/libgobject-2.0.so.0.5600.3)
==15710==    by 0x931EBA0: g_object_new (in /gnu/store/0q9pq9flr76rh4bv2524niknknnl2kvq-glib-2.56.3/lib/libgobject-2.0.so.0.5600.3)
==15710==    by 0x7541AA9: gtk_css_widget_node_new (in /gnu/store/h6dmb84rn291nwny73x3wfa1anh8n32g-gtk+-3.24.8/lib/libgtk-3.so.0.2404.4)
==15710==  Address 0x18 is not stack'd, malloc'd or (recently) free'd
```

After a double check with my previous working commit, I figure that I had accidentally removed

```
	gtk_init(NULL, NULL);
```

GTK was never initialized!
With that back in place, everything works.

That said, I'm very curious why everything works perfectly _with_ hardware acceleration enabled, but not without.  Does hardware acceleration somehow call gtk_init()?

[Carlos Garcia Campos]

We call gtk_init_check() when creating the PlatformDisplay, I guess when AC mode is enabled, PlatformDisplay is created earlier and gtk_init is called before  webkit_web_view_new_with_context().