*** empty log message ***

diff --git a/configure.ac b/configure.ac
index 651cda26b6987d39f57f7d427bfab80c39acb2dd..4d2593a5fa65892d4fdf3cc1fc6080c6dcf369f6 100644 (file)
--- a/configure.ac
+++ b/configure.ac
@@ -1,7 +1,7 @@
 AC_INIT
 AC_CONFIG_SRCDIR([ev_epoll.c])
 
-AM_INIT_AUTOMAKE(libev,3.33)
+AM_INIT_AUTOMAKE(libev,3.4)
 AC_CONFIG_HEADERS([config.h])
 AM_MAINTAINER_MODE
 

diff --git a/ev.pod b/ev.pod
index ee00c063296752167cae70110f1767901dd50569..bb4243659b49384334ce9655e5a99b6933ba357c 100644 (file)
--- a/ev.pod
+++ b/ev.pod
@@ -3354,6 +3354,32 @@ implementations implementing IEEE 754 (basically all existing ones).
 If you know of other additional requirements drop me a note.
 
 
+=head1 VALGRIND
+
+Valgrind has a special section here because it is a popular tool that is
+highly useful, but valgrind reports are very hard to interpret.
+
+If you think you found a bug (memory leak, uninitialised data access etc.)
+in libev, then check twice: If valgrind reports something like:
+
+   ==2274==    definitely lost: 0 bytes in 0 blocks.
+   ==2274==      possibly lost: 0 bytes in 0 blocks.
+   ==2274==    still reachable: 256 bytes in 1 blocks.
+
+then there is no memory leak. Similarly, under some circumstances,
+valgrind might report kernel bugs as if it were a bug in libev, or it
+might be confused (it is a very good tool, but only a tool).
+
+If you are unsure about something, feel free to contact the mailing list
+with the full valgrind report and an explanation on why you think this is
+a bug in libev. However, don't be annoyed when you get a brisk "this is
+no bug" answer and take the chance of learning how to interpret valgrind
+properly.
+
+If you need, for some reason, empty reports from valgrind for your project
+I suggest using suppression lists.
+
+
 =head1 AUTHOR
 
 Marc Lehmann <libev@schmorp.de>.