On Fri, 7 Jun 2019 19:30:40 +0200, Mike Wey wrote:

On 07-06-2019 19:04, Alex X wrote:

On Fri, 7 Jun 2019 16:46:48 +0200, Mike Wey wrote:

On 07-06-2019 05:26, Alex X wrote:

After trying the new idea of drawing on to the parent widget I am getting crashes in the code

static extern(C) void gtkd_container_remove(GtkContainer* c, GtkWidget* w)
{
	import gobject.c.functions : g_object_get_data;

	if ( auto container = cast(Container)g_object_get_data(cast(GObject*)c, "GObject") )
		if ( auto widget = cast(Widget)g_object_get_data(cast(GObject*)w, "GObject") )
	{
		import std.algorithm : remove;
		container.children.remove!(a => a is widget)();
	}
}

in Container.d

I'm not sure exactly why, it might be my code, but obviously it should not crash.

Exception thrown: read access violation.
std.range.primitives.front!(gtk.Widget.Widget).front(...) returned 0xFFFFFFFFFFFFFFFF.

The code should probably check for this and ignore such errors?

Should be fixed in:
https://github.com/gtkd-developers/GtkD/commit/68b055389b0c35cf7c5b16e198ffd7ac3c060e89

This isn't stop the crashing, I noticed that gtkContainer was null but the children had an invalid array.

if (container.gtkContainer is null || container.children.empty || container.children.length > 1000000)

Seems to work.

I'm not sure what is going on though. But it seems logical that if the gtkContainer is null then it should not have any children. The length check is a practical catch, maybe not necessary but 1M widgets will surely never occur in practice.

Can you share the code that is causing this? It would be useful to be
able to reproduce this locally.

Unfortunately I can't ;/ It's in production code, I have no idea what is causing it and dustmite never works for me. It only started happening when I changed code to draw on the parent widget and that let me remove a drawingArea and then it started showing up...

It was coming out of run and during shut down.

I have not had the crash since adding that extra check though.