[Gtk2-perl-bugs] [Bug 498334] Memory leak in Gtk2::Box::query_child_packing

[gnome-perl (bugzilla.gnome.org) <bug...@bu...>]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=498334

  gnome-perl | Gtk2 | Ver: unspecified

muppet changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sc...@as...




------- Comment #4 from muppet  2007-12-10 07:34 UTC -------
Hrm.  I hate to go changing code all over the place if it's not really
necessary.  And i find it hard to believe that OUTLIST would have a leak this
bad that nobody has yet noticed.

The generated code goes like this:

        XSprePUSH;       EXTEND(SP,4);
        PUSHs(sv_newmortal());
        ST(0) = boolSV(expand);
        PUSHs(sv_newmortal());
        ST(1) = boolSV(fill);
        PUSHs(sv_newmortal());
        sv_setuv(ST(2), (UV)padding);
        PUSHs(sv_newmortal());
        ST(3) = newSVGtkPackType (pack_type);

In three cases, push a new mortal onto the stack, then discard the pointer to
it.  I may be wrong, but i think that the perl garbage collector is not a pure
heap scanner, and can only free the scalar if it knows about it.  Even adding a
SAVETMPS/FREETMPS pair doesn't seem to do anything.

In xsubpp, the relevant piece of code is:

            elsif ($do_push) {
                print "\tPUSHs(sv_newmortal());\n";
                $arg = "ST($num)";
                eval "print qq\a$expr\a";
                warn $@   if  $@;
                print "\tSvSETMAGIC($arg);\n" if $do_setmagic;
            }

Now, the code for the UV OUTLIST arg padding looks correct --- push a new
scalar onto the stack, and alter it.  All of the rest are using typemaps that
overwrite the stack value.

But the T_GPERL_GENERIC_WRAPPER uses the form (simplified)

        $arg = newSV$typename ($var);

because it's easy and sensible.  Without changing the convention to saying
"hey, you need to provide a set_sv$typename(), or providing a richer set of
typemaps and utility functions, then we may be somewhat screwed.

So, it seems that you must take great care with the typemap used for the
datatype in the OUTLIST slot.  Perl's built-in typemaps for things like
integer, double, and string types seem to be safe.  When in doubt, check the
typemap.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=498334.