Sign up

Using a stack allocated VariantBuilder

Hello,

I'm using glibd in a GDBus server of mine and overall I really enjoy using it. However, I started profiling the thing with Valgrind and noticed some memory leaks, especially around using VariantBuilder. So I thought it might be a good idea to use the stack allocated VariantBuilders and explicitly call .clear on those to avoid leaking memory, but the following piece of code SIGSEGVs for me:

import glib.VariantBuilder;
import glib.VariantType;

void main() {
	VariantBuilder builder;
	builder.init(new VariantType("a(s)"));
}

I'm not exactly sure what I'm doing wrong, since this (seemingly) equivalent piece of code written with the C API seems to work:

import glib.c.types;
import glib.c.functions;
import glib.VariantType;

void main() {
	GVariantBuilder builder;
	g_variant_builder_init(&builder, new VariantType("a(s)").getVariantTypeStruct(true));
}

FWIW in my actual code I did something like this:

Variant getAll()
{
    auto builder = new VariantBuilder(new VariantType("a{sv}"));

    builder.open(new VariantType("{sv}"));
    builder.addValue(new Variant("allowUntrustedRepos"));
    builder.addValue(new Variant(new Variant(this.allowUntrustedRepositories)));
    builder.close();

    builder.open(new VariantType("{sv}"));
    builder.addValue(new Variant("root"));
    builder.addValue(new Variant(new Variant(this.root)));
    builder.close();

    return builder.end();
}

And apparently that leaks memory - or was that just Valgrind not liking what the GC did?

Re: Using a stack allocated VariantBuilder

On 19-05-2020 21:00, Rasmus Thomsen wrote:

Hello,

I'm using glibd in a GDBus server of mine and overall I really enjoy using it. However, I started profiling the thing with Valgrind and noticed some memory leaks, especially around using VariantBuilder. So I thought it might be a good idea to use the stack allocated VariantBuilders and explicitly call .clear on those to avoid leaking memory, but the following piece of code SIGSEGVs for me:

import glib.VariantBuilder;
import glib.VariantType;

void main() {
	VariantBuilder builder;
	builder.init(new VariantType("a(s)"));
}

I'm not exactly sure what I'm doing wrong, since this (seemingly) equivalent piece of code written with the C API seems to work:

import glib.c.types;
import glib.c.functions;
import glib.VariantType;

void main() {
	GVariantBuilder builder;
	g_variant_builder_init(&builder, new VariantType("a(s)").getVariantTypeStruct(true));
}

FWIW in my actual code I did something like this:

Variant getAll()
{
     auto builder = new VariantBuilder(new VariantType("a{sv}"));

     builder.open(new VariantType("{sv}"));
     builder.addValue(new Variant("allowUntrustedRepos"));
     builder.addValue(new Variant(new Variant(this.allowUntrustedRepositories)));
     builder.close();

     builder.open(new VariantType("{sv}"));
     builder.addValue(new Variant("root"));
     builder.addValue(new Variant(new Variant(this.root)));
     builder.close();

     return builder.end();
}

And apparently that leaks memory - or was that just Valgrind not liking what the GC did?

Since VariantBuilder is a class it's not allocated on the stack, so
currently you are calling init on a null pointer.

GVariantBuilder is a struct so it's on the stack and the C code works
like expected.

As far as i know Valgrind does indeed have issues with the GC.

Re: Using a stack allocated VariantBuilder

Since VariantBuilder is a class it's not allocated on the stack, so
currently you are calling init on a null pointer.

Derp, right. I guess that makes the init() method a bit useless though?

As far as i know Valgrind does indeed have issues with the GC.

Ah, that's unfortunate, that makes it a bit hard to diagnose memory leaks.

Re: Using a stack allocated VariantBuilder

On 20-05-2020 13:23, Rasmus Thomsen wrote:

Since VariantBuilder is a class it's not allocated on the stack, so
currently you are calling init on a null pointer.

Derp, right. I guess that makes the init() method a bit useless though?

As far as i know Valgrind does indeed have issues with the GC.

Ah, that's unfortunate, that makes it a bit hard to diagnose memory leaks.

You could try calling destroy on the GtkD object, that should at least
free the memory that is used on the C side.

https://dlang.org/phobos/object.html#.destroy