Housekeeping on Sunday, 8th of March, Anno Domini MMIX, at the hour of the Tiger
[git/dscho.git] / source-1233277286.txt
blob4c5d7bd1dec490a2c8d1b5c9a5f8f75f6ada8d5d
1 More valgrind fun
3 So I spent quite a number of hours on that funny zlib/valgrind issue.  The
4 thing is, zlib people claim that even if their code accesses uninitialized
5 memory, it does not produce erroneous data (by cutting out the results of the
6 uninitialized data, which is cheaper than checking for the end of the buffer
7 in an unaligned manner), so zlib will always be special for valgrind.
9 However, the bug I was chasing is funny, and different from said issue.  zlib
10 deflates an input buffer to an output buffer that is exactly 58 bytes long.
11 But valgrind claims that the 52nd of those bytes is uninitialized, and _only_
12 that one.
14 But it is not.  It must be 0x2c, otherwise zlib refuses to inflate the
15 buffer.
17 Now, I went into a debugging frenzy, and finally found out that zlib just
18 passes fine (with the default suppressions because of the "cute" way it
19 uses uninitialized memory), _except_ when it is compiled with UNALIGNED_OK
20 defined.
22 Which Ubuntu does, of course.  Ubuntu, the biggest forker of all.
24 The bad part is that it sounds like a bug in valgrind, and I _could_ imagine
25 that it is an issue of an optimized memcpy() that copies int by int, and
26 that valgrind misses out on the fact that a part of that int is actually
27 _not_ uninitialized.
29 But my debugging session's results disagree with that.
31 With the help of Julian Seward, the original author of valgrind, I instrumented
32 zlib's source code so that valgrind checks earlier if the byte is initialized
33 or not, to find out where the reason of the issue lies.
35 The sad part is that when I added the instrumentation to both the _end_ of
36 the while() loop in compress_block() in zlib's trees.c, and just _after_ the
37 while() loop (whose condition is a plain ''variable < variable'' comparison,
38 nothing fancy, certainly not changing any memory), only the _latter_ catches
39 a valgrind error.
41 And that is truly strange.