OK so looking into this more, it looks like the issue is that an RGBA struct is being freed twice for some reason as it is consistently failing on the RGBA destructor as per the stack trace below from GDB. In my code I allocate an RGBA array for the palette and this allocation seems to be triggering the D GC which in term calls the RGBA destructor and attempt to call gdkrgbafree.

I'm a bit confused on RGBA works in GTK since it is a struct and not a GObject, am I correct in assuming that it is not reference counted or is there something covert happening under the hood?

Also, how are references to this struct managed. For example, when I pass an RGBA to the VTE widget, who's responsible for calling gdkrgbafree, me (i.e. GtkD) or VTE? I checked the VTE source code and don't see any gdkrgbafree so I assume it's the caller?

If that's the case, does this mean I need to maintain persistent references to the RGBA class to ensure the RGBA class doesn't go out of scope and D garbage collects while a widget is still referencing the underlying struct?

#0  0x00007ffff71435f8 in raise () from /usr/lib/libc.so.6
#1  0x00007ffff7144a7a in abort () from /usr/lib/libc.so.6
#2  0x00007ffff1d74e18 in g_slice_free1 () from /usr/lib/libglib-2.0.so.0
#3  0x0000000000850c24 in gdk.RGBA.RGBA.~this() (this=0x7ffff7f1c220) at ../../../.dub/packages/gtk-d-3.2.0/src/gdk/RGBA.d:91
#4  0x0000000000a985bf in rt_finalize2 ()
#5  0x0000000000a986a2 in rt_finalizeFromGC ()
#6  0x0000000000a94336 in gc.gc.Gcx.sweep() ()
#7  0x0000000000a94ae5 in gc.gc.Gcx.fullcollect(bool) ()
#8  0x0000000000a92b7b in gc.gc.Gcx.smallAlloc(ubyte, ref ulong, uint) ()
#9  0x0000000000a90669 in gc.gc.GC.malloc(ulong, uint, ulong*, const(TypeInfo)) ()
#10 0x0000000000a6970f in gc_qalloc ()
#11 0x0000000000a978e5 in rt.lifetime.__arrayAlloc(ulong, const(TypeInfo), const(TypeInfo)) ()
#12 0x0000000000a6b8b2 in _d_newarrayU ()
#13 0x0000000000a6b935 in _d_newarrayT ()
#14 0x0000000000838017 in gx.terminix.terminal.terminal.Terminal.applyPreference(immutable(char)[]) (this=0x7ffff7f2f000, key=...) at source/gx/terminix/terminal/terminal.d:640
#15 0x000000000083a0fc in gx.terminix.terminal.terminal.Terminal.this(immutable(char)[]).__dgliteral4!(gio.Settings.Settings).__dgliteral4(immutable(char)[], gio.Settings.Settings) (this=0x7ffff7f23ae0, Settings=0x7ffff7eb2a00, key=...) at source/gx/terminix/terminal/terminal.d:1040
#16 0x000000000087df4b in gio.Settings.Settings.callBackChanged(gtkc.giotypes.GSettings*, char*, gio.Settings.Settings) (settingsStruct=0x11316b0, 
    key=0x124d825 "background-transparency-percent", _settings=0x7ffff7eb2a00) at ../../../.dub/packages/gtk-d-3.2.0/src/gio/Settings.d:1547
#17 0x00007ffff1226aca in g_cclosure_marshal_VOID__STRINGv () from /usr/lib/libgobject-2.0.so.0

In case it helps, here's my code for this section, line 640 in the stack trace corresponds to the RGBA[palette] = new RBA[colors.length] line.

case SETTINGS_PROFILE_FG_COLOR_KEY, SETTINGS_PROFILE_BG_COLOR_KEY, SETTINGS_PROFILE_PALETTE_COLOR_KEY,
SETTINGS_PROFILE_USE_THEME_COLORS_KEY, SETTINGS_PROFILE_BG_TRANSPARENCY_KEY:
    RGBA fg;
    RGBA bg;
    if (gsProfile.getBoolean(SETTINGS_PROFILE_USE_THEME_COLORS_KEY)) {
        vte.getStyleContext().getColor(StateFlags.ACTIVE, fg);
        vte.getStyleContext().getBackgroundColor(StateFlags.ACTIVE, bg);
    } else {
        fg = new RGBA();
        bg = new RGBA();
        if (!fg.parse(gsProfile.getString(SETTINGS_PROFILE_FG_COLOR_KEY)))
            trace("Parsing foreground color failed");
        if (!bg.parse(gsProfile.getString(SETTINGS_PROFILE_BG_COLOR_KEY)))
            trace("Parsing background color failed");
    }
    bg.alpha = to!double(100 - gsProfile.getInt(SETTINGS_PROFILE_BG_TRANSPARENCY_KEY)) / 100.0;
    string[] colors = gsProfile.getStrv(SETTINGS_PROFILE_PALETTE_COLOR_KEY);
    RGBA[] palette = new RGBA[colors.length];
    foreach (i, color; colors) {
        palette[i] = new RGBA();
        if (!palette[i].parse(color)) trace("Parsing color failed " ~ colors[i]);
    }
    vte.setColors(fg, bg, palette);
    break;

On Thu, 14 Jan 2016 19:53:57 +0100, Mike Wey wrote:

vte.setColors is copying the colors, so it shouldn't cause any problems.
I'll try finding out where is the error is coming from.

Thanks Mike, I just found the problem. It is ColorChooserT.setRgba. The current method is structured like this:

		GdkRGBA* outcolor = new GdkRGBA;
		
		gtk_color_chooser_get_rgba(getColorChooserStruct(), outcolor);
		
		color = ObjectG.getDObject!(RGBA)(outcolor);

If I change it to the following code, problem appears to be fixed in the sense that I can't reproduce it:

        color = new RGBA();    

		gtk_color_chooser_get_rgba(getColorChooserStruct(), color.getRGBAStruct());

I'm not sure why my change fixes it, I only stumbled on this because there are very few spots where I use RGBA in my program and commenting stuff out narrowed it to one section where I pull colors from some ColorButtons. I made my change in the code because I know ObjectG.getDObject will return a new object if it can't find one and since this case is my definition new (since the struct is being created) I figure I'd try tweaking it.

I don't understand getDObject well enough though to say why this works?

On Thu, 14 Jan 2016 22:29:19 +0100, Mike Wey wrote:

Looks like the problem is that the handle/pointer is allocated on the gc
heap. and when the GC runs it collects the handle before finalizing the
RGBA class. So the handle/pointer isn't valid when rgba_free is called.

getDObject will just construct an new class for types not derived form
ObjectG.

Makes sense and thanks for the explanation. Coming from Java the difference between struct and class in terms of memory (stack versus heap) hasn't become intuitive yet.

On 01/15/2016 11:46 AM, Gerald Nunn wrote:

Mike I also have the issue with the StyleContext getColor and getBackgroundColor. This issue though looks fairly pervasive in GtkD though as anywhere there is an out parameter with a class it follows the pattern of creating the struct first and then the class. I assume though that is all done by the code generator so it just needs to be fixed once and the code re-generated?

I've switched it to using g_malloc0 for the out parameters.

https://github.com/gtkd-developers/GtkD/commit/18bf92c4f3b5e4b081b45d956930366d3d64f776

On Sat, 16 Jan 2016 14:56:56 GMT, Gerald Nunn wrote:

On Sat, 16 Jan 2016 14:28:10 +0100, Mike Wey wrote:

On 01/15/2016 11:46 AM, Gerald Nunn wrote:

Mike I also have the issue with the StyleContext getColor and getBackgroundColor. This issue though looks fairly pervasive in GtkD though as anywhere there is an out parameter with a class it follows the pattern of creating the struct first and then the class. I assume though that is all done by the code generator so it just needs to be fixed once and the code re-generated?

I've switched it to using g_malloc0 for the out parameters.

https://github.com/gtkd-developers/GtkD/commit/18bf92c4f3b5e4b081b45d956930366d3d64f776

Thanks for the very quick turn around on this, I build my app against the version in git and I can no longer reproduce the issue.

Any plans to roll out a new GtkD package for Dub with this fix, say a 3.2.2?