Here's a better backtrace:

+ Trace 232280

Looks like a bad 'type' value is being passed to glade_widget_adaptor_get_by_type()

I added some debug output to the code like so:


GladeWidgetAdaptor  *
glade_widget_adaptor_get_by_type (GType  type)
{
	g_printf("glade_widget_adaptor_get_by_type(%s)\n", g_type_name(type));
	if (adaptor_hash != NULL)
		return g_hash_table_lookup (adaptor_hash, &type);
	else
		return NULL;
}


When adding widgets that work, a sensible values were printed to the console, e.g.
glade_widget_adaptor_get_by_type(GtkMenuBar)

However, when trying to add an item to the menu hierarchy, the above code crashes in g_type_name()

First of all make sure you are not getting any relevant warning at init time
then I guess you will have to use gdb to track this issue.
rebuild with debug symbols and no optimization and add a break point at 
glade_widget_adaptor_get_by_type() before add the menu item.

There are no warning or error messages emitted before hitting this problem.

I have rebuilt with -g -O0, and added some more debug logging to glade_widget_adaptor_get_by_type() to try and shed some light on this.


The following log shows what is going on: http://pastebin.com/raw.php?i=VC0Zk4dZ

At the point of failure, the type (32038896) given to glade_widget_adaptor_get_by_type is that of GtkMenuItem. There was definitely an adaptor registered for this type as can be seen earlier in the log. At the end of the log, however, adaptor_hash no longer has a value for that type... (and g_type_name() crashes)


I have also verified that adaptor_hash is not changing value, and tried some other changes suggested by people on #gnome-hackers -- http://pastebin.com/raw.php?i=bevEVUnd

Try to see if you can spot when the adaptor is being removed from the hash table
btw you can join #glade3 @ irc.gimp.org so we can help you debug it

Things got even stranger when I added some further diagnostic code.

Even though g_hash_table_lookup fails to find an entry for the type, if I use g_hash_table_foreach to examine the contents of the hash, the entry is there.

The problem is that the GType value is being truncated to 32 bits.
My original logging statements were not revealing this because I was printing using %d.

The definition of glade_base_editor_signals[SIGNAL_BUILD_CHILD] needs to be fixed, since GType is a pointer-sized type (not uint sized).

I think this means we need a new marshaller of type (OBJECT:OBJECT,POINTER) in gtk-marshallers but am not sure how these should be authored (seems to be generated from glade-marshallers.list)

This bug can be reproduced on 64-bit Linux by using jemalloc instead of libc's malloc.

  LD_PRELOAD=/usr/local/lib/libjemalloc.so glade-3

jemalloc allocates memory using mmap(), which results in memory addresses above the lower 4GB boundary.

These memory addresses are then being truncated to 32 bits in glade and causing this bug (and potentially others.)

FreeBSD and NetBSD use jemalloc by default so will be affected, and Mac OS X's malloc also returns addresses above 4GB.

P.S: using jemalloc with glade 3.12.1 and following the same steps results in a segfault

Created attachment 251301 [details] [review]
Fix for reported issue

The patch fixes the reported issue.
Tested on linux x86_64 with jemalloc.

Good catch!

I used G_TYPE_GTYPE instead of G_TYPE_POINTER and no marshaler because glib-genmarshal does not have a type for GType :s


fixed in master, glade-3-8, glade-3-16 and glade-3-18 branches

hmm I forgot to mention you in the commit log, I will in the next release notes

Thanks for taking care of this!

*** Bug 670764 has been marked as a duplicate of this bug. ***