No, string handling is quite different from other types which are ref counted.

Nothing free that string from pygi_signal_closure_marshal(), or am I overlooking something?

found 2 other issues in that function:
1) g_value_get_enum will assert if it holds G_TYPE_FLAGS
2) GParamSpec is considered anGI_INFO_TYPE_OBJECT, so it also have to be special-cased there to do g_value_get_param() instead of g_value_get_object() otherwise it will warning.

(In reply to comment #2)
> Nothing free that string from pygi_signal_closure_marshal(), or am I
> overlooking something?

I think that's correct. Our current tests do not cover that code path, so we should add a test for this.

(In reply to comment #3)
> found 2 other issues in that function:
> 1) g_value_get_enum will assert if it holds G_TYPE_FLAGS

This should be fixed in the current code:

                case GI_INFO_TYPE_FLAGS:
                    arg.v_long = g_value_get_flags (value);
                    break;
                case GI_INFO_TYPE_ENUM:
                    arg.v_long = g_value_get_enum (value);
                    break;


> 2) GParamSpec is considered anGI_INFO_TYPE_OBJECT, so it also have to be
> special-cased there to do g_value_get_param() instead of g_value_get_object()
> otherwise it will warning.

I cannot currently confirm this, as currently it is impossible (or very hard) to instantiate a ParamSpec with PyGI. Once that is fixed, this should also get a test case.

Memory leaks mentioned will be fixed in work done with bug 726999.

Fixed with bug 726999