[Octave-patch-tracker] [patch #9060] Re-enable singleton cleanup (mostly)

[Robert Jenssen]

URL:
  <http://savannah.gnu.org/patch/?9060>

                 Summary: Re-enable singleton cleanup (mostly)
                 Project: GNU Octave
            Submitted by: morgawr
            Submitted on: Thu 28 Jul 2016 03:26:41 AM GMT
                Category: Core : other
                Priority: 5 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

This patch is a step in my quixotic quest to reduce the number of memory leak
warnings from valgrind and address-sanitizer. This patch report relates to:

1. Bug#44420 "Memory leaks in 4.0 RC"

2.
https://lists.gnu.org/archive/html/octave-maintainers/2012-01/msg00039.html
"Re: singleton cleanup issues (was: Re: Fwd: octave segfaults during exit"

3.
https://lists.gnu.org/archive/html/octave-maintainers/2011-12/msg00045.html
"Re: segfault on 'make check'"



The first patch is cleanup_1.patch. It makes the following changes:
1. Enables the call to singleton_cleanup_list::cleanup() in
libinterp/corefcn/interpreter.cc. This was commented out to fix the
make_int typeinfo segfault.
2. Disables singleton cleanup by typeinfo::cleanup_instance().
3. Disables singleton cleanup by ft_manager::cleanup_instance().



If ft_manager::cleanup_instance() is enabled, then the following
Octave code segfaults: "plot(0);legend('t');quit;", as shown in the attached
file legend_valgrind.log. It seems that there is graphics_object that
has not been freed by gh_manager::cleanup_instance() but is now being freed
by the finaliser for the liboctinterp.so.3.0.0 shared library. Unfortunately,
the FT face memory in the graphics_object has already been freed by
ft_manager::cleanup_instance(). Using this information I ran the gdb session
shown in legend_gdb.log. The session shows:
1. gh_manager is instantiated before ft_manager so
ft_manager::cleanup_instance()
is called before gh_manager::cleanup_instance().
2. The backtrace just before the segfault shows that the finaliser is trying
to delete a std::map object called dprop_obj_map that is instantiated at
graphics.cc:1694:
// Used to cache dummy graphics objects from which dynamic properties can be
// cloned.
static std::map<caseless_str, graphics_object> dprop_obj_map;



The second patch is cleanup_2.patch. In addition to cleanup_1.patch it:
1. Enables ft_manager::cleanup_instance()
2. Forces instantiation of ft_manager by inserting a dummy text_renderer
object before gh_manager in register_graphics_toolkit(). Maybe there is a
better way to do this.
3. Makes dprop_obj_map into a singleton class called dprop_obj_manager
that maps a property name into the graphics_handle of a graphics_object.
4. Makes singleton_cleanup_list use a stack instead of a set so that the
cleanup order is known to be the reverse of the order of addition to the 
list.

These changes are intended to force the order of instantiantion to be
ft_manager, gh_manager, dprop_obj_manager and the order of cleanup to be
dprop_obj_manager, gh_manager, ft_manager.



Future things to work on:

1. Add a function to unregister typeinfo so that typeinfo::cleanup_instance()
works with examples/code/make_int.cc. Modify that example to separate
the instantiation of type myint and the instantiation of objects of
type myint. Re-enable typeinfo::cleanup_instance().

2. Look at classdef cleanup

3. Fix FIXME in ft_manager::~ft_manager
Change the order of calls to FcInit and FT_Init_FreeType in
ft_manager::ft_manager(void). I have not found an Octave bug report for
the problem with fccache.c:507. I doubt that this is due to a bug in
fontconfig. I suspect this is more likely due to calls to FcFini() from 
both ft_manager::~ft_manager and the fltk library.

4. Look at interpreter memory usage during the processing of startup files





    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Thu 28 Jul 2016 03:26:41 AM GMT  Name: cleanup_1.patch  Size: 3kB   By:
morgawr
Patches to mostly re-enable singleton-cleanup
<http://savannah.gnu.org/patch/download.php?file_id=38036>
-------------------------------------------------------
Date: Thu 28 Jul 2016 03:26:41 AM GMT  Name: legend_gdb.log  Size: 28kB   By:
morgawr
Patches to mostly re-enable singleton-cleanup
<http://savannah.gnu.org/patch/download.php?file_id=38037>
-------------------------------------------------------
Date: Thu 28 Jul 2016 03:26:41 AM GMT  Name: cleanup_2.patch  Size: 7kB   By:
morgawr
Patches to mostly re-enable singleton-cleanup
<http://savannah.gnu.org/patch/download.php?file_id=38038>
-------------------------------------------------------
Date: Thu 28 Jul 2016 03:26:41 AM GMT  Name: legend_valgrind.log  Size: 28kB  
By: morgawr
Patches to mostly re-enable singleton-cleanup
<http://savannah.gnu.org/patch/download.php?file_id=38039>

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/patch/?9060>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/