Mail Archives: geda-user/2020/12/11/11:24:42
Hi Glenn,
On Tue, 8 Dec 2020, Glenn (glimrick AT epilitimus DOT com) [via
geda-user AT delorie DOT com] wrote:
> There is currently only one commit to the mem_leak branch, commit
> 5ccfd8b8a2
thank you for fixing these!
A few of the variables you freed were actually still in use, so I had to
change a few things. In particular, g_object_set_data takes a generic
pointer, so the string mustn't be freed while the object is still around.
In eda_config_get_context_for_file, the path object must only be freed if
it was created in the function or it would result in a double free; and in
restore_current_page, you accidentally freed the configuration context
instead of the retrieved string. I also moved the convenience function
you introduced to i_basic.c and made it static (no need to pollute the
global namespace with something that is only used once), removed a comment
which made only sense if you knew the previous version of the code
(comments like this go better into the commit message), simplified the
free handling in x_clipboard.c, and applied gEDA/gaf coding style.
May I ask how you proceeded to find these leaks? I always struggled to do
memory analysis on gschem because of the large amount of warnings
introduced by Guile and Gtk.
It will take me some more time to review the SAB patches; this is
something which requires my full attention, so I can't just fit it into
any free time slot.
Roland
- Raw text -