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/1ab97fe2e0c4222900bb6e4e8d54655cfefd87...)
- 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