Sat 02 Jul 2016 07:00:52 AM UTC, comment #8:
I've looked around a bit more and I think I understand things a little better. Sorry for the noise. I found the comment in toplev.cc about "Don't call singleton_cleanup_list ..." and uncommented the cleanup call and
commented the typeinfo cleanup call:
Now "cdef_manager::cleanup_instance()" gets called.
|
Fri 01 Jul 2016 01:16:41 AM UTC, comment #7:
I built a debug build of the development sources with:
+verbatim
diff -r f471f513ffd0 libinterp/corefcn/Cell.h
--- a/libinterp/corefcn/Cell.h Wed Jun 29 18:50:37 2016 -0400
+++ b/libinterp/corefcn/Cell.h Fri Jul 01 11:00:59 2016 +1000
@@ -41,7 +41,7 @@
public:
Cell (void)
- : Array<octave_value> (dim_vector (0, 0)) { }
+ : Array<octave_value> () { }
Cell (const octave_value& val)
: Array<octave_value> (dim_vector (1, 1), val) { }
-verbatim-
It passes "make check".
Most of the remaining leaks also appear to be due to reference counting in dim_vector and ArrayRep. For example valgrind shows:
and
|
Sat 21 Mar 2015 02:17:08 AM UTC, comment #6:
Using the valgrind log I can see that a whole slew of small 8 byte leaks are due to this code in ov-classdef.cc at line 701.
Everywhere an empty Cell() object is created causes a leak.
I believe the put routine is defined at ov-classdef.h:408.
Maybe when a map goes out of existence it is somehow failing to call the the destructor for the right-side value.
|
Wed 04 Mar 2015 03:32:49 PM UTC, comment #2:
Oops, wait, I think the way I was running make check made it so that I was only running valgrind on the driver program, not Octave itself.
Trying again by forcing octave-cli in the run-octave script. Now the tests are running much slower, so I think I'm using valgrind now. But so far no messages either. I'll let it run and see what happens.
I guess we need a way to be able to specify both -valgrind and -cli as options for the run-octve script...
|