Probably harmless GTK assertion failures in gtk_notebook_get_tab_label #22176
Comments
|
This is still very annoying, but I just don't seem to be able to do anything about this, the assertion fails inside a function called from FWIW here is the simplest possible GTK program, based on their own hello world, sufficient to reproduce the problem: just closing the window results in (only once because there is only one page, there is one of those per page). #include <gtk/gtk.h>
static void
activate (GtkApplication* app,
gpointer user_data)
{
GtkWidget *window;
window = gtk_application_window_new (app);
gtk_window_set_title (GTK_WINDOW (window), "Window");
gtk_window_set_default_size (GTK_WINDOW (window), 200, 200);
GtkWidget* notebook = gtk_notebook_new();
GtkWidget* button = gtk_button_new_with_label("First");
gtk_notebook_append_page(GTK_NOTEBOOK(notebook), button, NULL);
gtk_container_add (GTK_CONTAINER (window), notebook);
gtk_widget_show_all (window);
}
int
main (int argc,
char **argv)
{
GtkApplication *app;
int status;
app = gtk_application_new ("org.gtk.example", G_APPLICATION_FLAGS_NONE);
g_signal_connect (app, "activate", G_CALLBACK (activate), NULL);
status = g_application_run (G_APPLICATION (app), argc, argv);
g_object_unref (app);
return status;
} |
|
OK, so I think the only way to do something about this is to ignore this specific GTK error while the pages are being removed. It looks like it's not that difficult to do, we can just set our own log writer function for the required scope and "handle" (i.e. filter) the messages of this form. This could also be used for other unwanted GTK logs, of course, without suppressing all of them as |
These messages are due to an assertion failure deep inside ATK which doesn't indicate any real problem (as failure to get the label of an already destroyed tab is normal and is already handled correctly in the GTK code) and can't be avoided, so suppress them to avoid showing them to the users who can't do anything at all about them anyhow, but can be scared by the "CRITICAL" GTK messages. Closes wxWidgets#22176.
Make GTK notebook log suppression opt-in to avoid a fatal error when the application calls g_log_set_writer_func() itself, as doing it more than once immediately kills the application with glib 2.73 and there is no way to check if it had been already done or not (you have to admire the purity of the API design here). This is unfortunate as 99% of the wxWidgets applications that do _not_ call g_log_set_writer_func() would now show the spurious diagnostics by default again, but preferable to making the remaining 1% crash, and there doesn't seem to be any other solution. Call the new GTKAllowDiagnosticsControl() function in the notebook sample to at least still avoid getting the spurious diagnostic messages described in wxWidgets#22176 there. See wxWidgets#22717,.
Make GTK notebook log suppression opt-in to avoid a fatal error when the application calls g_log_set_writer_func() itself, as doing it more than once immediately kills the application with glib 2.73 and there is no way to check if it had been already done or not (you have to admire the purity of the API design here). This is unfortunate as 99% of the wxWidgets applications that do _not_ call g_log_set_writer_func() would now show the spurious diagnostics by default again, but preferable to making the remaining 1% crash, and there doesn't seem to be any other solution. Call the new GTKAllowDiagnosticsControl() function in the notebook sample to at least still avoid getting the spurious diagnostic messages described in wxWidgets#22176 there. See wxWidgets#22717,.
Make GTK notebook log suppression opt-in to avoid a fatal error when the application calls g_log_set_writer_func() itself, as doing it more than once immediately kills the application with glib 2.73 and there is no way to check if it had been already done or not (you have to admire the purity of the API design here). This is unfortunate as 99% of the wxWidgets applications that do _not_ call g_log_set_writer_func() would now show the spurious diagnostics by default again, but preferable to making the remaining 1% crash, and there doesn't seem to be any other solution. Call the new GTKAllowDiagnosticsControl() function in the notebook sample to at least still avoid getting the spurious diagnostic messages described in wxWidgets#22176 there. See wxWidgets#22717. (cherry picked from commit 8af645e)
Make GTK notebook log suppression opt-in to avoid a fatal error when the application calls g_log_set_writer_func() itself, as doing it more than once immediately kills the application with glib 2.73 and there is no way to check if it had been already done or not (you have to admire the purity of the API design here). This is unfortunate as 99% of the wxWidgets applications that do _not_ call g_log_set_writer_func() would now show the spurious diagnostics by default again, but preferable to making the remaining 1% crash, and there doesn't seem to be any other solution. Call the new GTKAllowDiagnosticsControl() function in the notebook sample to at least still avoid getting the spurious diagnostic messages described in wxWidgets#22176 there. See wxWidgets#22717. (cherry picked from commit 8af645e and adapted to 3.2 stable ABI).
When destroying
wxNotebookwe get warnings like this (for each notebook page):This happens in
and probably just because the page actually isn't there any longer, so it's probably harmless, but the warnings are still annoying and I don't think we were getting them before, but not sure about what could have changed.
The text was updated successfully, but these errors were encountered: