Re: Callback inheritance problem with Gtk.TextBuffer and llvm-gcc > 4.2




On Jun 8, 2013, at 2:27 PM, Johan Dahlin <johan gnome org> wrote:

If you run your program under valgrind, will it report any relevant errors?

Remember to use the python supressions file, or you'll get a lot of
false positives.

I'm on OSX 10.8, which isn't well supported by Valgrind. It does have a 
pretty good built-in memory analyzer, and I find from that that the address
causing the error (0x07a7b830 with malloc debugging turned on) is in a single
1K allocation block:
MALLOC_TINY            07a00000-07b00000 [ 1024K  1024K  1024K] rw-/rwx SM=COW  DefaultMallocZone_0x1bf000

It hasn't been scribbled:
(gdb) x /32xw 0x07a7b800
0x7a7b800: 0x02989970 0x02f0ea20 0x00000000 0xaaaaaaaa
0x7a7b810: 0xa7b810b8 0xb2a6e907 0xaaaafaf4 0x030fd2fc
0x7a7b820: 0x02956a20 0x030fd2f0 0x07a7b810 0xaaaaaaaa
0x7a7b830: 0xa7b830b8 0xb286e907 0xaaaafaf4 0x00a6c26c
0x7a7b840: 0x02956a20 0x00a6c260 0x07a7b830 0xaaaaaaaa
0x7a7b850: 0x00000002 0x00000000 0x00000037 0x07a7b610
0x7a7b860: 0x002b7320 0x00000088 0x00000005 0x00000000
0x7a7b870: 0x00000000 0x02f8dd40 0x00000000 0x07a7b610

Looking a bit deeper into the assignment of the callback, though, it appears to me that the offset for the callback
is a bit large:
(gdb) up
#1  0x02f0a02e in g_type_class_meta_marshal (closure=0x7a79d70, return_value=0x0, n_param_values=3, param_values=0xbfff8660, invocation_hint=0xbfff85e0, marshal_data=0x5c) at gclosure.c:970
970    closure->marshal (closure,
(gdb) list
965  guint offset = GPOINTER_TO_UINT (marshal_data);
966
967  class = G_TYPE_INSTANCE_GET_CLASS (g_value_peek_pointer (param_values + 0), itype, GTypeClass);
968  callback = G_STRUCT_MEMBER (gpointer, class, offset);
969  if (callback)
970    closure->marshal (closure,
971      return_value,
972      n_param_values, param_values,
973      invocation_hint,
974      callback);

I suspect that for some reason the marshal_data value (0x5c) is wrong; it would have been set in a call to g_signal_type_cclosure_new(), but I don't know how to find the right instance of that to probe the actual class
struct and see what the offset really should be or if it's a pointer that's getting overwritten.

Regards,
John Ralls




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]