chromium 117.0.5938.149-1 gtk+3 crash (without atk)

[kyx0r]

Hi. I am back on Xorg. Done fighting battles with wayland.

My chrome crashes with this:
chromium 117.0.5938.149-1

[22597:22597:1007/212351.509479:ERROR:browser_main_loop.cc(275)] Gtk: gtk_text_view_set_buffer: assertion
'buffer == NULL || GTK_IS_TEXT_BUFFER (buffer)' failed
[22597:22597:1007/212351.509495:ERROR:browser_main_loop.cc(275)] GLib-GObject: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
[22597:22597:1007/212351.509501:ERROR:browser_main_loop.cc(275)] Gtk: gtk_text_buffer_get_insert: assertion 'GTK_IS_TEXT_BUFFER (buffer)' failed
[22597:22597:1007/212351.509507:ERROR:browser_main_loop.cc(275)] Gtk: gtk_text_buffer_get_iter_at_mark: assertion 'GTK_IS_TEXT_MARK (mark)' failed
Segmentation fault

I built a slightly newer version, but even the one you have currently crashes the same way.
Just press any key on your keyboard and it crashes.

Mouse works just fine.

Is it just my system? I don't have any issues like that in other gtk+3 apps on xorg.

Kind Regards,
Kyryl

[kyx0r]

P.S this crash does not happen on wayland.

[kyx0r]

Ok I figured it out.

Turns out I did not have atk on my system. That causes gtk+3 to be compiled without no-fribidi.patch.
When atk is installed and gtk recompiled problem goes away.

@ehawkvu I remeber atk being a dependency of chromium. I guess it was removed.

[echawk]

Thanks for investigating this! I've had an unrelated crash w/ chromium that seems to have fixed itself?? (Look at the irc logs between me and sewn for more info on this). I'll re-add atk as a dependency. I'll see if there is an easy way to check if gtk+3 was compiled w/ atk support.

[echawk]

Here's the patch that I'm thinking of adding, thoughts?

diff --git a/community/chromium/build b/community/chromium/build
index 0fe68674..7bfac2f0 100755
--- a/community/chromium/build
+++ b/community/chromium/build
@@ -2,6 +2,33 @@
 
 export DESTDIR="$1"
 
+# Check to make sure that gtk+3 is built with atk support
+cat > gtk-atk-test.c <<EOF
+#include <gtk/gtk.h>
+
+int main () {
+#ifdef GTK_ACCESSIBLE
+  return 0;
+#else
+  return 1;
+#endif
+}
+EOF
+"${CC:-cc}" $(pkg-config --cflags gtk+-3.0) gtk-atk-test.c -o gtk-atk-test
+if ! ./gtk-atk-test; then
+cat <<EOF
+You need to rebuild gtk+3 with atk support!
+
+If you are using the version of gtk+3 shipped with kiss-xorg run the following:
+
+$ kiss b gtk+3
+
+And it will automatically pick up the atk dependency.
+EOF
+    exit 1
+fi
+rm -v -- gtk-atk-test.c
+
 printf "NOTE: It is HIGHLY recommended to build this package with sane build flags and 'ccache' enabled!\n"
 
 # Glob includes the libstdc++ patchset aswell.

[apprehensions]

I think we should patch fribidi or/and atk patched out of chromium. I would do it if I wasn't on Alpine.

[kyx0r]

Looks like a nice workaround, despite being super hacky.

I wouldn't know how feasible it is to patch the chrome itself.
You can use kiss on alpine and compile it over there. Also,try building in chroot to prevent filesystem poisoning.

[echawk]

What's odd is that this problem does not occur on the wayland version of chrome - they use almost the same patches that we do. I think that gtk+3 is the place to look since for X11 we require a couple extra steps to ensure that atk is not built into the library.

[echawk]

I'm not a huge fan of how hacky this solution is either, but without seriously investigating why gtk+3 has different behavior on X vs wayland when atk is patched out, I'm inclined to merge it on the next version bump.

[echawk]

@kyx0r hacky fix was pushed up last night. I wonder if it would be possible to build chromium using only the qt5 toolkit, instead of gtk3? (I have not tried to build chromium w/o gtk+3, but I do wonder if it would be feasible).

[kyx0r]

Oh my, I am not brave enough to compile qt5. Isn't it like crazy bloated last time I've checked?

[echawk]

@kyx0r compared to gtk3 it's pretty bloated, but overall it's not crazy. On my system (granted w/ -O3 -march=native) qt5 takes up 110MB and takes about 10 minutes to compile (16 threads)

[apprehensions]

Wait, rebuilding GTK+3 with ATK support, while Chromium still has ATK support disabled, fixes this problem..?

The issue is indeed in gtk+3. Which is weird since the two ATK patches don't actually add lines..

[apprehensions]

Here is a small gtk3 program that intentionally triggers the segfault but that segfault only occurs when gtk is built without atk (yes, i asked chatgpt to write it because i cant be assed with gtk)

#include <gtk/gtk.h>

// Callback function to handle key presses
static gboolean on_key_press(GtkWidget *widget, GdkEventKey *event, GtkTextBuffer *buffer) {
    if (event->keyval == GDK_KEY_Escape) {
        gtk_main_quit();  // Close the application when Esc key is pressed
        return TRUE;
    }

    // Set the buffer to NULL to trigger the error
    gtk_text_view_set_buffer(GTK_TEXT_VIEW(widget), NULL);

    // Try to get the insert mark from the NULL buffer
    GtkTextMark *insert = gtk_text_buffer_get_insert(NULL);
    if (insert == NULL) {
        g_print("Error: gtk_text_buffer_get_insert failed\n");
    }

    // Try to get the iterator at a NULL mark
    GtkTextIter iter;
    gtk_text_buffer_get_iter_at_mark(NULL, &iter, NULL);

    return TRUE;
}

int main(int argc, char *argv[]) {
    gtk_init(&argc, &argv);

    // Create a window
    GtkWidget *window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
    gtk_window_set_default_size(GTK_WINDOW(window), 400, 300);
    gtk_window_set_title(GTK_WINDOW(window), "Simple Text Editor");
    g_signal_connect(G_OBJECT(window), "destroy", G_CALLBACK(gtk_main_quit), NULL);

    // Create a text view
    GtkWidget *text_view = gtk_text_view_new();

    // Get the text buffer associated with the text view
    GtkTextBuffer *buffer = gtk_text_view_get_buffer(GTK_TEXT_VIEW(text_view));

    // Set up the key press event handler
    g_signal_connect(G_OBJECT(text_view), "key-press-event", G_CALLBACK(on_key_press), buffer);

    // Create a scrollable container for the text view
    GtkWidget *scrolled_window = gtk_scrolled_window_new(NULL, NULL);
    gtk_container_add(GTK_CONTAINER(scrolled_window), text_view);

    // Add the scrolled window to the main window
    gtk_container_add(GTK_CONTAINER(window), scrolled_window);

    // Show all widgets
    gtk_widget_show_all(window);

    // Start the GTK main loop
    gtk_main();

    return 0;
}

[echawk]

@apprehensions does that code also segfault if you were to run it under a wayland environment (like if someone was using upstreams' version of gtk+3). Good find btw, should make it much more straightforward to try and pinpoint where this problem is.