GNOME Bugzilla – Bug 769076
Fix warning: attempt to override closure->va_marshal with new marshal
Last modified: 2016-10-27 12:31:34 UTC
Created attachment 331981 [details] [review] Fix warning: attempt to override closure->va_marshal with new marshal On MSYS2 I observe warning: (gtk3-demo.exe:6692): GLib-GObject-WARNING **: attempt to override closure->va_marshal (63c488b0) with new marshal (66926178) The attached trivial patch fixes this warning. I would rather encourage to use the g_cclosure_marshal_VOID__* variants than the via #define _gtk_marshal_VOID__* derived names in g_signal_new. This may better indicate to not add subsequent g_signal_set_va_marshaller. Anyway, since both variants exist in the gobject code basis, I did not changed it. PS: I'm not familiar with gobject. Fix was derived from what has been observed from debugging of the above noted warning.
I don't understand how that warning comes to be. Afaics glib will not set a va marshaller itself (unless the marshaller in gsignal_new() is NULL and it clearly isn't), so there is no marshaller that could be overridden when we call that function. Another thing that confuses me: This is all code that has been around since 2012 and is not Windows-specific, so how come this warning only shows up in 2016?
1) The marshaller is written in g_signal_newv: ... else if (n_params == 1 && return_type == G_TYPE_NONE) { #define ADD_CHECK(__type__) \ else if (g_type_is_a (param_types[0] & ~G_SIGNAL_TYPE_STATIC_SCOPE, G_TYPE_ ##__type__)) \ { \ builtin_c_marshaller = g_cclosure_marshal_VOID__ ## __type__; \ va_marshaller = g_cclosure_marshal_VOID__ ## __type__ ##v; \ } if (0) {} ADD_CHECK (BOOLEAN) ADD_CHECK (CHAR) ... 2) >This is all code that has been around since 2012 ... No, related code was introduced with: https://github.com/GNOME/gtk/commit/51d58108f93261d6311f823736ce92369272d491 "Add some va marshallers to frequent signals" Matthias Clasen committed on Apr 19
Huh indeed, the code uses the generic va marshaller even if it doesn't use the generic C marshaller. That seems wrong to me. But let's get an opinion from glib developers.
Only a minor text correction to my initial post, last sentence. It should note gtk instead of gobject code basis: Anyway, since both variants exist in the gtk+ code basis, I did not changed it.
Created attachment 332275 [details] [review] Don't set a va marshaller if a marshaller was set Otherwise we get warnings when the caller later tries to set a va marshaller with g_signal_set_va_marshaller.
Created attachment 332281 [details] [review] tests: Add test showing default marshaller override
*** Bug 770392 has been marked as a duplicate of this bug. ***
Thanks, all - been wondering about this one for a while, but despite normally being great at searching, never found any useful discussion, never mind a ticket, till I unknowingly opened a dupe today. Could we expect the fix to be committed sometime soon?
Review of attachment 332275 [details] [review]: This looks good to me, and a good fix, because a nonstandard marshaller could have a very different behaviour than the default ones.
Would be great to get this into stable as well.
Review of attachment 332281 [details] [review]: ack
Attachment 332275 [details] pushed as ef16cbe - Don't set a va marshaller if a marshaller was set Attachment 332281 [details] pushed as edfbfc1 - tests: Add test showing default marshaller override
This is causing a crash in gtk+ when clicking other locations in file picker or nautilus. [hussam@hades ~]$ coredumpctl gdb 2094 PID: 2094 (nautilus) UID: 1000 (hussam) GID: 100 (users) Signal: 5 (TRAP) Timestamp: Mon 2016-08-29 15:20:23 EEST (22s ago) Command Line: nautilus Executable: /usr/bin/nautilus Control Group: /user.slice/user-1000.slice/user@1000.service/gnome-terminal-server.service Unit: user@1000.service User Unit: user@1000.service Slice: user-1000.slice Owner UID: 1000 (hussam) Boot ID: 77b8e8cc52e645308f915bad239cf3e4 Machine ID: efb490e643e2436d9d1138df1745a008 Hostname: hades Coredump: /var/lib/systemd/coredump/core.nautilus.1000.77b8e8cc52e645308f915bad239cf3e4.2094.1472473223000000000000.lz4 Message: Process 2094 (nautilus) of user 1000 dumped core. Stack trace of thread 2094: #0 0x00007f01353ccec1 _g_log_abort (libglib-2.0.so.0) #1 0x00007f01353ce2cd g_logv (libglib-2.0.so.0) #2 0x00007f01353ce42f g_log (libglib-2.0.so.0) #3 0x00007f013569f105 g_closure_invoke (libgobject-2.0.so.0) #4 0x00007f01356b1bb2 signal_emit_unlocked_R (libgobject-2.0.so.0) #5 0x00007f01356baacc g_signal_emit_valist (libgobject-2.0.so.0) #6 0x00007f01356baeaf g_signal_emit (libgobject-2.0.so.0) #7 0x00007f0137015c8a emit_show_other_locations_with_flags (libgtk-3.so.0) #8 0x00007f013569f105 g_closure_invoke (libgobject-2.0.so.0) #9 0x00007f01356b1bb2 signal_emit_unlocked_R (libgobject-2.0.so.0) #10 0x00007f01356baacc g_signal_emit_valist (libgobject-2.0.so.0) #11 0x00007f01356baeaf g_signal_emit (libgobject-2.0.so.0) #12 0x00007f0136fbda6f gtk_list_box_multipress_gesture_released (libgtk-3.so.0) #13 0x00007f012f4851c8 ffi_call_unix64 (libffi.so.6) #14 0x00007f012f484c2a ffi_call (libffi.so.6) #15 0x00007f013569fe1a g_cclosure_marshal_generic_va (libgobject-2.0.so.0) #16 0x00007f013569f334 _g_closure_invoke_va (libgobject-2.0.so.0) #17 0x00007f01356ba7bd g_signal_emit_valist (libgobject-2.0.so.0) #18 0x00007f01356baeaf g_signal_emit (libgobject-2.0.so.0) #19 0x00007f0136f77d05 gtk_gesture_multi_press_end (libgtk-3.so.0) #20 0x00007f01356a1eb7 g_cclosure_marshal_VOID__BOXEDv (libgobject-2.0.so.0) #21 0x00007f013569f334 _g_closure_invoke_va (libgobject-2.0.so.0) #22 0x00007f01356ba7bd g_signal_emit_valist (libgobject-2.0.so.0) #23 0x00007f01356baeaf g_signal_emit (libgobject-2.0.so.0) #24 0x00007f0136f7485e _gtk_gesture_set_recognized (libgtk-3.so.0) #25 0x00007f0136f75ffb gtk_gesture_handle_event (libgtk-3.so.0) #26 0x00007f0136f79456 gtk_gesture_single_handle_event (libgtk-3.so.0) #27 0x00007f0136f3ffbe gtk_event_controller_handle_event (libgtk-3.so.0) #28 0x00007f013712b51b _gtk_widget_run_controllers (libgtk-3.so.0) #29 0x00007f0136fc6b61 _gtk_marshal_BOOLEAN__BOXEDv (libgtk-3.so.0) #30 0x00007f013569f334 _g_closure_invoke_va (libgobject-2.0.so.0) #31 0x00007f01356ba291 g_signal_emit_valist (libgobject-2.0.so.0) #32 0x00007f01356baeaf g_signal_emit (libgobject-2.0.so.0) #33 0x00007f013712de3c gtk_widget_event_internal (libgtk-3.so.0) #34 0x00007f0136fc382e propagate_event_up (libgtk-3.so.0) #35 0x00007f0136fc59a8 gtk_main_do_event (libgtk-3.so.0) #36 0x00007f0136aa1dc5 _gdk_event_emit (libgdk-3.so.0) #37 0x00007f0136ad5b62 gdk_event_source_dispatch (libgdk-3.so.0) #38 0x00007f01353c7457 g_main_dispatch (libglib-2.0.so.0) #39 0x00007f01353c76c0 g_main_context_iterate (libglib-2.0.so.0) #40 0x00007f01353c776c g_main_context_iteration (libglib-2.0.so.0) #41 0x00007f0135987a5d g_application_run (libgio-2.0.so.0) #42 0x0000000000428b5a main (nautilus) #43 0x00007f0134add291 __libc_start_main (libc.so.6) #44 0x0000000000428baa _start (nautilus) Stack trace of thread 2097: #0 0x00007f0134b9c15d poll (libc.so.6) #1 0x00007f01353c7656 g_main_context_poll (libglib-2.0.so.0) #2 0x00007f01353c776c g_main_context_iteration (libglib-2.0.so.0) #3 0x00007f01353c77b1 glib_worker_main (libglib-2.0.so.0) #4 0x00007f01353eee05 g_thread_proxy (libglib-2.0.so.0) #5 0x00007f0134e62404 start_thread (libpthread.so.0) #6 0x00007f0134ba549f __clone (libc.so.6) Stack trace of thread 2110: #0 0x00007f0134b9c15d poll (libc.so.6) #1 0x00007f01353c7656 g_main_context_poll (libglib-2.0.so.0) #2 0x00007f01353c776c g_main_context_iteration (libglib-2.0.so.0) #3 0x00007f01225814bd n/a (libdconfsettings.so) #4 0x00007f01353eee05 g_thread_proxy (libglib-2.0.so.0) #5 0x00007f0134e62404 start_thread (libpthread.so.0) #6 0x00007f0134ba549f __clone (libc.so.6) Stack trace of thread 2098: #0 0x00007f0134b9c15d poll (libc.so.6) #1 0x00007f01353c7656 g_main_context_poll (libglib-2.0.so.0) #2 0x00007f01353c79e2 g_main_loop_run (libglib-2.0.so.0) #3 0x00007f01359b4c76 gdbus_shared_thread_func (libgio-2.0.so.0) #4 0x00007f01353eee05 g_thread_proxy (libglib-2.0.so.0) #5 0x00007f0134e62404 start_thread (libpthread.so.0) #6 0x00007f0134ba549f __clone (libc.so.6) Stack trace of thread 2099: #0 0x00007f0134ba0bd9 syscall (libc.so.6) #1 0x00007f013540ccda g_cond_wait_until (libglib-2.0.so.0) #2 0x00007f013539be99 g_async_queue_pop_intern_unlocked (libglib-2.0.so.0) #3 0x00007f013539c4bc g_async_queue_timeout_pop (libglib-2.0.so.0) #4 0x00007f01353ef8cd g_thread_pool_wait_for_new_pool (libglib-2.0.so.0) #5 0x00007f01353eee05 g_thread_proxy (libglib-2.0.so.0) #6 0x00007f0134e62404 start_thread (libpthread.so.0) #7 0x00007f0134ba549f __clone (libc.so.6) GNU gdb (GDB) 7.11.1 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/bin/nautilus...done. [New LWP 2094] [New LWP 2097] [New LWP 2110] [New LWP 2098] [New LWP 2099] warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". Core was generated by `nautilus'. Program terminated with signal SIGTRAP, Trace/breakpoint trap.
+ Trace 236605
Reverting the commit makes things work again..
That crash was a GTK bug, fixed in bug 770550.
Hi all, Unfortunately, commit https://git.gnome.org/browse/glib/commit/?id=ef16cbe breaks mate-display-properties (app from mate-control-center package) in GTK+3 build of MATE. A black rectangle is shown in the place where currently plugged monitors should be shown. Additionally, there's a warning in the terminal: (mate-display-properties:31711): display-properties-CRITICAL **: foo_marshal_VOID__POINTER_BOXED_POINTER: assertion 'n_param_values == 4' failed The affected code is here: https://github.com/mate-desktop/mate-control-center/blob/master/capplets/display/scrollarea.c#L320 What can be done here? If needed, I can post this as separate report, or change the status of this one. If you need I can also post the screenshot of the broken app.
You use the right marshal - The code in question specifies foo_marshal_VOID__POINTER_BOXED_POINTER as marshal but only has 1 POINTER argument. So I guess you want foo_marshal_VOID__POINTER.
Hmm... wonder how that worked all the way with previous versions of GLib...
glib ignored the marshal argument and used its own. That's what this patch has fixed.
Ah, now it's clear. Thanks. Good to know it's not a regression. Now that I see the answer, I wonder how I missed the obvious mistake in our code... :)