[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Octave-bug-tracker] [bug #55287] Memory leak in graphics subsystem
From: |
John W. Eaton |
Subject: |
[Octave-bug-tracker] [bug #55287] Memory leak in graphics subsystem |
Date: |
Fri, 18 Jan 2019 08:22:24 -0500 (EST) |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 |
Follow-up Comment #61, bug #55287 (project octave):
If you change the ft_text_renderer destructor to also display the size of the
strlist member variable, you'll see that it is zero each time the destructor
is called for the text objects contained in the axes object. But if you run a
number of plot commands without doing clf, then when you quit Octave, you'll
see a large value for the size of strlist. I guess this comes from the axes
object. It must be the action of getting the extents of the tick labels.
This makes sense to me, since the render code calls accept/visit for the text
objects and render clears strlist. But the get_extent code, which also calls
accept/visit and appends to strlist does not clear strlist like render does.
The following change seems to avoid the leak for me, but I'm not sure which of
the two get_extent functions should really be calling strlist.clear().
diff --git a/libinterp/corefcn/ft-text-renderer.cc
b/libinterp/corefcn/ft-text-renderer.cc
--- a/libinterp/corefcn/ft-text-renderer.cc
+++ b/libinterp/corefcn/ft-text-renderer.cc
@@ -1242,6 +1250,7 @@ namespace octave
ft_text_renderer::get_extent (const std::string& txt, double rotation,
const caseless_str& interpreter)
{
+ strlist.clear ();
text_element *elt = text_parser::parse (txt, interpreter);
Matrix extent = get_extent (elt, rotation);
delete elt;
Maybe there is a better place to clear strlist? It seems to me that it should
be called after executing accept/visit (when we are done with the strlist
object) instead of calling it before accept/visit (to clean up after a
previous call that appends to strlist). But I don't really understand how
this is supposed to work, so I'll leave that up to you.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?55287>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
- [Octave-bug-tracker] [bug #55287] Memory leak in graphics subsystem, (continued)
- [Octave-bug-tracker] [bug #55287] Memory leak in graphics subsystem, Rik, 2019/01/14
- [Octave-bug-tracker] [bug #55287] Memory leak in graphics subsystem, Pantxo Diribarne, 2019/01/14
- [Octave-bug-tracker] [bug #55287] Memory leak in graphics subsystem, Rik, 2019/01/14
- [Octave-bug-tracker] [bug #55287] Memory leak in graphics subsystem, Rik, 2019/01/15
- [Octave-bug-tracker] [bug #55287] Memory leak in graphics subsystem, Rik, 2019/01/15
- [Octave-bug-tracker] [bug #55287] Memory leak in graphics subsystem, Philip Nienhuis, 2019/01/17
- [Octave-bug-tracker] [bug #55287] Memory leak in graphics subsystem, Rik, 2019/01/17
- [Octave-bug-tracker] [bug #55287] Memory leak in graphics subsystem, Robert F, 2019/01/17
- [Octave-bug-tracker] [bug #55287] Memory leak in graphics subsystem, Pantxo Diribarne, 2019/01/18
- [Octave-bug-tracker] [bug #55287] Memory leak in graphics subsystem, Pantxo Diribarne, 2019/01/18
- [Octave-bug-tracker] [bug #55287] Memory leak in graphics subsystem,
John W. Eaton <=
- [Octave-bug-tracker] [bug #55287] Memory leak in graphics subsystem, Pantxo Diribarne, 2019/01/18
- [Octave-bug-tracker] [bug #55287] Memory leak in graphics subsystem, Rik, 2019/01/18