summaryrefslogtreecommitdiff
path: root/ev.pod
diff options
context:
space:
mode:
authorroot <root>2008-05-20 20:00:34 +0000
committerroot <root>2008-05-20 20:00:34 +0000
commitc204ee30e962b3af31eb37c9ba3154d5cebaba04 (patch)
tree85be8ebc104e29e0d434c4a4d8ea5a30070122a7 /ev.pod
parente41363f983e45e61b9a6f6b1b2f906c7d39c5a54 (diff)
*** empty log message ***
Diffstat (limited to 'ev.pod')
-rw-r--r--ev.pod26
1 files changed, 26 insertions, 0 deletions
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 <libev@schmorp.de>.