Bug 1260577

(In reply to Thomas Haller from comment #0)

>   - with a GEnum typed argument

GFlags actually... didn't test with GEnum.

This indeed looks like a glib or ffi bug. Could we do with something less invasive to work around it? Something along the lines of

diff --git a/src/nm-config.c b/src/nm-config.c
index d805948..c782616 100644
--- a/src/nm-config.c
+++ b/src/nm-config.c
@@ -1890,7 +1890,13 @@ nm_config_class_init (NMConfigClass *config_class)
                          G_SIGNAL_RUN_FIRST,
                          G_STRUCT_OFFSET (NMConfigClass, config_changed),
                          NULL, NULL, NULL,
-                         G_TYPE_NONE, 3, NM_TYPE_CONFIG_DATA, NM_TYPE_CONFIG_CHANGE_FLAGS, NM_TYPE_CONFIG_DATA);
+                         G_TYPE_NONE, 3, NM_TYPE_CONFIG_DATA,
+                         /* https://bugzilla.redhat.com/show_bug.cgi?id=1260577 */
+                         /* NM_TYPE_CONFIG_CHANGE_FLAGS, */
+                         G_TYPE_UINT,
+                         NM_TYPE_CONFIG_DATA);
+
+       G_STATIC_ASSERT (sizeof (guint) == sizeof (NMConfigChangeFlags));
 }
 
 static void

or maybe even ifdef'd with defined(__s390x__) || defined (__PPC64__) or whichever platforms are known broken; and maybe a test to make sure we didn't leave out any platform?

See https://bugzilla.gnome.org/show_bug.cgi?id=686662

(In reply to Colin Walters from comment #4)
> See https://bugzilla.gnome.org/show_bug.cgi?id=686662

I don't think this is related.

Note that for both NetworkManager and the attached reproducer, the enum is of 4 bytes (same as gint/guint).

Also note, that the test doesn't fail, if only one handler is connected to the signal.

You could determine if it's FFI by using a generated marshaller instead of g_cclosure_marshal_generic.

Hardware watchpoints might help figure out when the variable is being changed?  Or alternatively, just add some debugging printfs into libgobject?

(In reply to Colin Walters from comment #6)
> You could determine if it's FFI by using a generated marshaller instead of
> g_cclosure_marshal_generic.
> 
> Hardware watchpoints might help figure out when the variable is being
> changed?  Or alternatively, just add some debugging printfs into libgobject?

The test-program also fails with glib from upstream master.
Also, the failure is for GEnum too (not only GFlags).


While gclosure.c has some special handling for GEnum types, GFlags are treated just like a guint. As the error doesn't happen with G_TYPE_UINT/G_TYPE_INT as signal type, that hints that the error is not in libffi.

But since gclosure.c doesn't handly GFlags differently from guint, it seems to hint that the error isn't in gclosure either.


Anyway, I don't know...

(In reply to Lubomir Rintel from comment #3)
> This indeed looks like a glib or ffi bug. Could we do with something less
> invasive to work around it? Something along the lines of

added this workaround to NM: http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=e7d66f1df61ebdc7652ba34a4e1baddcc86b9e26

Fixed upstream now: https://bugzilla.gnome.org/show_bug.cgi?id=754882

I can do the backport as soon as the flags come in.

This is a low risk fix.  Can someone please set the blocker flag?

I've verified this bug according the reproducer in comment 0 on all archs: x86_64, s390x, ppc64 and ppc64le. On all these archs the reproducer passed.

The reproducer has been added into our standard glib2 automation testset.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2116.html