Bug #81934 for Math-GSL: Matrix & Vector OO routines' memory management responsibilities are not documented

Wed Dec 12 16:56:25 2012 jthorn [...] astro.indiana.edu - Ticket created

Subject:

Matrix & Vector OO routines' memory management responsibilities are not documented

Summary: The documentation for Math::GSL::Matrix (and also Math::GSL::Vector) doesn't describe the memory-management responsibilities for client code using the OO routines. In particular, it doesn't say who is responsible for freeing the underlying GSL matrix object created by Math::GSL::Matrix->new(). Details: Consider the attached test program. After RTFM (both the CPAN web pages and 'man Math::GSL::Matrix') I couldn't tell whether or not it would leak memory. That is, I couldn't find any documented statement answering the question asked in the comment in the function foo(): In a function which has just done my $M = Math::GSL::Matrix->new(1000, 1000); do we (the client code) need to explicitly free the underlying GSL matrix object (when we're through with it) in order to avoid a memory leak? Or does this happen automagically when Perl garbage-collects $M (some time after goes out of scope at the end of this function)? By watching the process size while running this test program, I determined that I do in fact need to explicitly free the underlying GSL matrix object. The bug I'm reporting is that the documentation doesn't seem to say who is responsible for the memory management. (I emphasize that I am *not* suggesting that the attached test program's memory leak is a bug.) I don't think this bug is system-dependent, but just for completness: I'm using Math::GSL version 0.27, installed from the CPAN tarball. % uname -a OpenBSD cobalt.astro.indiana.edu 5.1 GENERIC.MP#1 amd64 % perl -v This is perl 5, version 12, subversion 2 (v5.12.2 (*)) built for amd64-openbsd (with 8 registered patches, see perl -V for more detail) Copyright 1987-2010, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using "man perl" or "perldoc perl". If you have access to the Internet, point your browser at http://www.perl.org/, the Perl Home Page. %

Subject:

try-matrix-memory-leak

Download try-matrix-memory-leak
application/octet-stream 755b

Message body not shown because it is not plain text.

Sat Oct 01 23:33:09 2016 jonathan [...] leto.net - Correspondence added

Howdy, Thanks for the bug report. I am actually not seeing the memory leak behavior on the latest Math::GSL 0.39 on OS X with Perl 5.18.2 and GSL 2.2.1. I also tested on Ubuntu 14.10/Perl 5.20.1 and I don't see the leak there either. If I instead modify the script to push onto a global array, I then see the (expected) "leaking" of memory: https://gist.github.com/leto/74463cba03b329856a40cdd4682a4417 Could you test again with Math::GSL 0.39 to see if it still happens for you? This could be OS/compiler/Perl version dependent. There are a lot of variables at play. What you expected *should* have happen: once a Math::GSL object goes out of scope, it should be garbage collected. Duke On Wed Dec 12 16:56:25 2012, jthorn@astro.indiana.edu wrote: Show quoted text

> Summary: > > The documentation for Math::GSL::Matrix (and also Math::GSL::Vector) > doesn't describe the memory-management responsibilities for client code > using the OO routines. In particular, it doesn't say who is responsible > for freeing the underlying GSL matrix object created by > Math::GSL::Matrix->new(). > > > Details: > > Consider the attached test program. > After RTFM (both the CPAN web pages and 'man Math::GSL::Matrix') I > couldn't tell whether or not it would leak memory. > > That is, I couldn't find any documented statement answering the question > asked in the comment in the function foo(): In a function which has > just done > > my $M = Math::GSL::Matrix->new(1000, 1000); > > do we (the client code) need to explicitly free the underlying GSL > matrix object (when we're through with it) in order to avoid a memory > leak? Or does this happen automagically when Perl garbage-collects $M > (some time after goes out of scope at the end of this function)? > > By watching the process size while running this test program, I > determined that I do in fact need to explicitly free the underlying GSL > matrix object. > > The bug I'm reporting is that the documentation doesn't seem to say who > is responsible for the memory management. (I emphasize that I am *not* > suggesting that the attached test program's memory leak is a bug.) > > > > I don't think this bug is system-dependent, but just for completness: > > I'm using Math::GSL version 0.27, installed from the CPAN tarball. > > % uname -a > OpenBSD cobalt.astro.indiana.edu 5.1 GENERIC.MP#1 amd64 > % perl -v > > This is perl 5, version 12, subversion 2 (v5.12.2 (*)) built for > amd64-openbsd > (with 8 registered patches, see perl -V for more detail) > > Copyright 1987-2010, Larry Wall > > Perl may be copied only under the terms of either the Artistic License > or the > GNU General Public License, which may be found in the Perl 5 source kit. > > Complete documentation for Perl, including FAQ lists, should be found on > this system using "man perl" or "perldoc perl". If you have access to the > Internet, point your browser at http://www.perl.org/, the Perl Home Page. > > %

Sat Oct 01 23:33:09 2016 The RT System itself - Status changed from 'new' to 'open'