[Geany-Devel] Memory leaks in Geany

[Colomban Wendling]

Le 25/09/2013 00:02, Pavel Roschin a écrit :
> I checked Geany with valgrind with this command line:
> G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --tool=memcheck
> --leak-check=full --log-file=vgdump --suppressions=gtk.suppression
> --track-origins=yes --show-possibly-lost=no src/geany
> 
> gtk.suppression you may find here: https://wiki.gnome.org/Valgrind
> 
> Report: https://gist.github.com/scriptum/6691838
> 
> Possible leaks:
> - symbols.c:1877

Fixed, thanks
(https://github.com/geany/geany/commit/1ab97fe2e0c4222900bb6e4e8d54655cfefd8756)

> - somewhere in tag manager (too many possibly leaks reported)
> 
> Other suggestions:
> - enable -Wall -Wextra -Werror in compiler

Yes, kinda advertized in HACKING -- but -Werror is harder to use because
you need to check your flags VERY carefully not to produce any false
positive.  E.g. -Wwrite-strings have a few false positive due to
imperfect API.  But yeah, it's nice to stop on possible errors.  FTR, we
(devs) all (I believe) use this or stricter options (but maybe not with
-Werror).

> - add cppcheck into makefile

We have this in geany-plugins.  I'm not sure how useful it was 'til now,
but at least it didn't report false positives.  Out of curiosity, did
cppcheck report any errors?

> - add valgrind command line and exceptions into project

Maybe we should at least document it yeah.

> - make debugging mode that toggles with defines/environment vars

You mean the various -DDEBUG_STUFF?  Those are a bit too specific in
general, e.g. if you enable this for CTags you'll get a lot of debugging
prints that are of no interest if debugging anything else (and even
might make it harder to see what you want).

And for environment vars, what are you referring to?  G_DEBUG= and
G_SLICE= ?  IMO that's to be set by the caller depending on the need.
E.g. I have custom GDB and Valgrind run scripts that set those as needed
-- and these don't need the same actually, Valgrind needs
resident-modules to have a chance to see a leak in a loaded module, but
GDB don't since it's used to analyze running code.

Regards,
Colomban