maria-developers team mailing list archive

[worklog-noreply@xxxxxxxxxxxx]

-----------------------------------------------------------------------
                              WORKLOG TASK
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
TASK...........: Using the Valgrind API in mysqld
CREATION DATE..: Fri, 22 May 2009, 11:43
SUPERVISOR.....: Monty
IMPLEMENTOR....: Knielsen
COPIES TO......: 
CATEGORY.......: Server-RawIdeaBin
TASK ID........: 23 (http://askmonty.org/worklog/?tid=23)
VERSION........: Benchmarks-3.0
STATUS.........: Assigned
PRIORITY.......: 60
WORKED HOURS...: 0
ESTIMATE.......: 40 (hours remain)
ORIG. ESTIMATE.: 40

PROGRESS NOTES:

-=-=(Knielsen - Fri, 22 May 2009, 11:52)=-=-
High-Level Specification modified.
--- /tmp/wklog.23.old.17628     2009-05-22 11:52:33.000000000 +0300
+++ /tmp/wklog.23.new.17628     2009-05-22 11:52:33.000000000 +0300
@@ -1 +1,28 @@
+With custom memory allocators, using the Valgrind APIs we can tell Valgrind when
+a memory block is allocated (so that data read from memory is marked as undefined
+instead of being defined or not at random depending on prior use); and when a
+memory block is freed (so that use after freeing can be reported as an error).
 
+In some cases cheking for leaks may also be appropriate.
+
+Another possibility is to add an explicit check for whether memory is defined.
+
+One place this would be useful is when calling libz. Due to the design of that
+library, Valgrind produces lots of false alarms about using undefined values
+(I think the issue is that it runs a few bytes off of initialized memory to
+reduce boundary checks in each loop iteration, then after the loop has checks to
+avoid using the undefined part of the result). This means we have lots of libz
+Valgrind suppressions and continue to add more as new warnings surface. So we
+might easily miss a real problem in this area. This could be improved by adding
+explicit checks at the call to libz functions that the passed memory is properly
+defined.
+
+Another use is to improve debugging. It is often the case when debugging a
+warning about using un-initialised memory that the detection happens long after
+the real problem, the un-initialized value being passed along through the code
+for a long time before being detected. This makes debugging the problem slow.
+
+By adding in strategic places code that asserts that a specific value must be
+initialised, it is possible to detect problems earlier, speeding up debugging.
+Such code can be added in more places over time as development and debugging
+goes on.



DESCRIPTION:

Valgrind (the memcheck tool) has some very useful APIs that can be used in mysqld
when testing with Valgrind to improve testing and/or debugging:

    file:///usr/share/doc/valgrind/html/mc-manual.html#mc-manual.clientreqs
    file:///usr/share/doc/valgrind/html/mc-manual.html#mc-manual.mempools

This worklog is about adding configure checks and headers to allow to use these
in a way that continues to work on machines where the Valgrind headers or
functionality is missing.

It also includes adding some basic Valgrind enhancements:

 - Adding Valgrind annotations to custom memory allocators so that Valgrind can
   detect leaks, use-before-init, and use-after-free problems also for these
   allocators.

 - Adding checks for definedness in appropriate places (eg. when calling libz).


HIGH-LEVEL SPECIFICATION:



With custom memory allocators, using the Valgrind APIs we can tell Valgrind when
a memory block is allocated (so that data read from memory is marked as undefined
instead of being defined or not at random depending on prior use); and when a
memory block is freed (so that use after freeing can be reported as an error).

In some cases cheking for leaks may also be appropriate.

Another possibility is to add an explicit check for whether memory is defined.

One place this would be useful is when calling libz. Due to the design of that
library, Valgrind produces lots of false alarms about using undefined values
(I think the issue is that it runs a few bytes off of initialized memory to
reduce boundary checks in each loop iteration, then after the loop has checks to
avoid using the undefined part of the result). This means we have lots of libz
Valgrind suppressions and continue to add more as new warnings surface. So we
might easily miss a real problem in this area. This could be improved by adding
explicit checks at the call to libz functions that the passed memory is properly
defined.

Another use is to improve debugging. It is often the case when debugging a
warning about using un-initialised memory that the detection happens long after
the real problem, the un-initialized value being passed along through the code
for a long time before being detected. This makes debugging the problem slow.

By adding in strategic places code that asserts that a specific value must be
initialised, it is possible to detect problems earlier, speeding up debugging.
Such code can be added in more places over time as development and debugging
goes on.


ESTIMATED WORK TIME

ESTIMATED COMPLETION DATE
-----------------------------------------------------------------------
WorkLog (v3.5.9)