From 88c44a919b6f4bf322ab45041a2ef5995c76d294 Mon Sep 17 00:00:00 2001
From: mmccutchen <mmccutchen@837edb03-e0f3-0310-88ca-d4d4e8b29345>
Date: Mon, 22 Mar 2010 17:07:26 +0000
Subject: [PATCH] Add tooling for running under Valgrind.

git-svn-id: http://supertux.lethargik.org/svn/supertux/trunk/supertux@6622 837edb03-e0f3-0310-88ca-d4d4e8b29345
---
 tools/valgrind/README        | 19 +++++++++++
 tools/valgrind/run           |  7 ++++
 tools/valgrind/supertux.supp | 79 ++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 105 insertions(+)
 create mode 100644 tools/valgrind/README
 create mode 100755 tools/valgrind/run
 create mode 100644 tools/valgrind/supertux.supp

diff --git a/tools/valgrind/README b/tools/valgrind/README
new file mode 100644
index 000000000..010ea15d0
--- /dev/null
+++ b/tools/valgrind/README
@@ -0,0 +1,19 @@
+You can use this script and suppressions file to run SuperTux under Valgrind
+( http://www.valgrind.org/ ) to catch memory errors and leaks.
+
+Some things to be aware of:
+
+- Some C++ objects appear to use interior pointers, which will cause valgrind to
+  report parts of their still-reachable instances as "possibly lost".  You can
+  ignore those reports.
+
+- In the GNU C++ library, a std::string object contains a pointer to a
+  heap-allocated "representation" buffer containing the actual data.  If you
+  free a heap-allocated std::string S without destructing it (uncommon but not
+  unheard of), you'll leak the representation.  But representations are shared
+  and copied on write, so if S was a copy of another string S', Valgrind will
+  blame the leak on the code that created S' because that was when the
+  representation was allocated.  (Valgrind doesn't know any better without
+  instrumenting constructors and destructors.)  Watch out for this.  When it
+  first happened to me (Matt McCutchen), I was stumped for a while; finally,
+  I wrote some small test programs and realized what was happening.
diff --git a/tools/valgrind/run b/tools/valgrind/run
new file mode 100755
index 000000000..1eed452e3
--- /dev/null
+++ b/tools/valgrind/run
@@ -0,0 +1,7 @@
+#!/bin/bash
+# Script to launch supertux under valgrind for memory error/leak checking.
+# This is meant to be called as "tools/valgrind/run" from the top of the tree.
+
+valgrind --log-file=valgrind.log --suppressions=tools/valgrind/supertux.supp \
+	--gen-suppressions=all --leak-check=full --num-callers=20 \
+	./supertux2 "$@"
diff --git a/tools/valgrind/supertux.supp b/tools/valgrind/supertux.supp
new file mode 100644
index 000000000..1683b1ad4
--- /dev/null
+++ b/tools/valgrind/supertux.supp
@@ -0,0 +1,79 @@
+# Valgrind suppressions file for SuperTux
+#
+# Started by Matt McCutchen <matt@mattmccutchen.net> 2010-02-18
+
+# Various errors observed in libraries and not investigated.
+{
+   SDL-Cond
+   Memcheck:Cond
+   fun:SDL_SYS_JoystickInit
+}
+{
+   SDL-Cond2
+   Memcheck:Cond
+   fun:X11_SetKeyboardState
+}
+{
+   nvidia-libGLcore-Cond
+   Memcheck:Cond
+   obj:/usr/lib*/nvidia/libGLcore.so*
+}
+{
+   nvidia-libGL-malloc-Leak
+   Memcheck:Leak
+   fun:malloc
+   obj:/usr/lib*/nvidia/libGL.so*
+}
+{
+   nvidia-libGL-calloc-Leak
+   Memcheck:Leak
+   fun:calloc
+   obj:/usr/lib*/nvidia/libGL.so*
+}
+{
+   nvidia-libGL-realloc-Leak
+   Memcheck:Leak
+   fun:realloc
+   obj:/usr/lib*/nvidia/libGL.so*
+}
+{
+   nvidia-libGL-dlopen-Leak
+   Memcheck:Leak
+   ...
+   fun:dlopen*
+   obj:/usr/lib*/nvidia/libGL.so*
+}
+{
+   alsa-lib-Leak
+   Memcheck:Leak
+   ...
+   fun:parse_defs
+}
+{
+   SDL-create_aux_windows-Leak
+   Memcheck:Leak
+   ...
+   fun:create_aux_windows
+}
+{
+   openal-init-Leak
+   Memcheck:Leak
+   ...
+   fun:snd1_dlobj_cache_add
+}
+{
+   dlclose-Leak
+   Memcheck:Leak
+   ...
+   fun:dlclose
+}
+
+# Memory leak in libselinux, should be fixed in current Fedora 12:
+# http://cvs.fedoraproject.org/viewvc/rpms/libselinux/F-12/libselinux-rhat.patch?r1=1.199&r2=1.200
+#{
+#   libselinux-Leak
+#   Memcheck:Leak
+#   ...
+#   fun:getdelim
+#   fun:init_lib
+#}
-- 
2.11.0