From c204ee30e962b3af31eb37c9ba3154d5cebaba04 Mon Sep 17 00:00:00 2001 From: root Date: Tue, 20 May 2008 20:00:34 +0000 Subject: *** empty log message *** --- configure.ac | 2 +- ev.pod | 26 ++++++++++++++++++++++++++ 2 files changed, 27 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 651cda2..4d2593a 100644 --- 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 ee00c06..bb42436 100644 --- 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 . -- cgit v1.2.3