GNOME Bugzilla – Bug 327419
g_object_compat_control is G_DISABLE_DEPRECATED, potentially causing crashes on 64-bit systems
Last modified: 2006-01-19 08:51:07 UTC
Steps to reproduce: FreeBSD-CURRENT just recently got a new malloc implementation which favors the use of mmap() over the more traditional brk() functions where possible. This has the added side-effect that malloc now has the potential to return addresses above the magical 4GB marker. Those addresses obviously do not fit inside a 32bit unsigned int. The use of GPOINTER_TO_UINT is obviously causing the dropping of the high-bit for those addresses resulting in faulty memory addresses all over the place, most easily noticeable by any call to gtk_window_new(). Rebuilding my libc with -DUSE_BRK (to avoid the allocation of memory above the 4GB marker) seems to make any crashes observed disappear .. so i am quite confident that this is the root of the issue observed. This crashing behaviour has been observer on FreeBSD/amd64. Stack trace: Stack traces are rather meaningless in this case ... Other information:
Any such place is a bug. We should only GPOINTER_TO_UINT when we stuffed an int in there first by GUINT_TO_POINTER It would be extremely helpful if you could try to find places where this breaks.
I am not exactly knowledgable on glib-code myself so it's really hard for me to point out locations that are potential causes. However during my gdb-session fairly shortly before the segmentation fault happened the code went through glib/glib/gdataset.c:616 (on glib-2.9.3) .. my first guess would be to have a closer look at the g_quark_* set of functions.
On a sidenote .. it is probably worth mentioning that the same problem does NOT occur with glib-2.8.5 and my gdb-session seemed to indicate that the issue that triggers this specifically is directly related to the following changelog entries in glib-2.9.2 and gtk-2.8.10 respectively: [ from the glib-2.9.2 changelog ] * Type system: - introduce a new type GInitiallyUnowned, which has an initial floating reference. [Tim] - Add support for GType parameters. [Matthias] [ from the gtk-2.8.10 changelog ] * Derive GtkObject from GInitiallyUnowned instead of GObject, if possible. Note that this change is known to break versions of the GTK+ Perl bindings older than GTK+ Perl 2.13.4. [Tim Janik] The code execution path (as observed by lots of "step/stepi" calls in gdb) seemed to go on and on regarding "GInitiallyUnowned" .. which would explain why this behavior has not been seen in glib-2.8.5 since GInitiallyUnowned got introduced with glib-2.9.2. I hope this gives enough information to start a more focused search.
Line 616 is a hashtable lookup of g_quark_ht. GQuarks are guint32s, so they should survive fine going between pointers and ints. The cast doesn't involved any values returned from malloc(). Judging from this and comment #3, it seems that GPOINTER_TO_UINT has nothing to do with this problem. You need to provide a small, simple testcase, and the full backtrace from the crash from that.
The easiest test i can think of right now .. would be running gtk-demo. Which gives the following backtrace: Core was generated by `gtk-demo'. Program terminated with signal 11, Segmentation fault.
+ Trace 65313
Thread 1 (LWP 100156)
The variable pnode ((TypeNode *) 0x4018b30) in stackframe #0 is a typical example of a faulty memory address.
The assumption that is made gtype is that you can store pointers in GType, where GType is usually unsigned long. You can see that in type_node_any_new_W(), type = (GType) node;
Reporter, can you attach your glibconfig.h that's generated from your 2.9.x install here?
I think we found the likely cause for this. g_object_compat_control() was G_DISABLE_DEPRECATED, so it was not visible when compiling GTK+. This is bad for a function returning a 64bit value... Should be fixed by recompiling GTK+ against GLib 2.9.4/2.8.6
Created attachment 57633 [details] glibconfig.h for glib-2.9.3 generated on FreeBSD/amd64 7.0-CURRENT This is the requested glibconfig.h for a glib-2.9.3 build. A rebuild of GTK-2.8.10 against glib-2.9.4 does seem to indeed resolve the original mass breakage observed.