From f62f49b4faeb477b348f51f3865dc9f4650d3029 Mon Sep 17 00:00:00 2001 From: Johannes Schindelin Date: Fri, 30 Jan 2009 02:01:28 +0100 Subject: [PATCH] Update Friday, 30th of January, Anno Domini MMIX, at the hour of the Buffalo Signed-off-by: Johannes Schindelin --- index.html | 105 +++++++++++++++++++++++--------------------------- source-1233277286.txt | 41 ++++++++++++++++++++ 2 files changed, 89 insertions(+), 57 deletions(-) create mode 100644 source-1233277286.txt diff --git a/index.html b/index.html index f20bda96f3..fcd13e7d48 100644 --- a/index.html +++ b/index.html @@ -12,6 +12,7 @@ Table of contents:

- Older posts + Older posts
@@ -86,6 +86,52 @@
+
Friday, 30th of January, Anno Domini MMIX, at the hour of the Buffalo
+ +

More valgrind fun

+ +

+

+ So I spent quite a number of hours on that funny zlib/valgrind issue. The + thing is, zlib people claim that even if their code accesses uninitialized + memory, it does not produce erroneous data (by cutting out the results of the + uninitialized data, which is cheaper than checking for the end of the buffer + in an unaligned manner), so zlib will always be special for valgrind. +

+ However, the bug I was chasing is funny, and different from said issue. zlib + deflates an input buffer to an output buffer that is exactly 58 bytes long. + But valgrind claims that the 52nd of those bytes is uninitialized, and only + that one. +

+ But it is not. It must be 0x2c, otherwise zlib refuses to inflate the + buffer. +

+ Now, I went into a debugging frenzy, and finally found out that zlib just + passes fine (with the default suppressions because of the "cute" way it + uses uninitialized memory), except when it is compiled with UNALIGNED_OK + defined. +

+ Which Ubuntu does, of course. Ubuntu, the biggest forker of all. +

+ The bad part is that it sounds like a bug in valgrind, and I could imagine + that it is an issue of an optimized memcpy() that copies int by int, and + that valgrind misses out on the fact that a part of that int is actually + not uninitialized. +

+ But my debugging session's results disagree with that. +

+ With the help of Julian Seward, the original author of valgrind, I instrumented + zlib's source code so that valgrind checks earlier if the byte is initialized + or not, to find out where the reason of the issue lies. +

+ The sad part is that when I added the instrumentation to both the end of + the while() loop in compress_block() in zlib's trees.c, and just after the + while() loop (whose condition is a plain variable < variable comparison, + nothing fancy, certainly not changing any memory), only the latter catches + a valgrind error. +

+ And that is truly strange. +

Thursday, 29th of January, Anno Domini MMIX, at the hour of the Buffalo

Interactive stash

@@ -508,61 +554,6 @@ exec > pipe 2>&1 Of course, the hardest part is to find a nice user interface for that. Maybe --colored-words? ☺

-
Saturday, 24th of January, Anno Domini MMIX, at the hour of the Pig
- -

Ideas for a major revamp of the --preserve-merges handling in git rebase

- -

-

- As probably everybody agrees, the code to preserve merges is a big mess - right now. -

- Worse, the whole concept of "pick " just does not fly well. -

- So I started a major cleanup, which happens to reduce the code very - nicely so far. -

- It will take a few days to flesh out, I guess, but these are the major - ideas of my work: -

- pick $sha1
-

will only work on non-merges in the future.
- merge $sha1 [$sha1...] was $sha1 Merge ...
-
will merge the given list of commits into the current HEAD, for - the user's reference and to keep up-to-date what was rewritten, - the original merge is shown after the keyword "was" (which is not - a valid SHA-1, luckily).
- goto $sha1
-
will reset the HEAD to the given commit.
- $sha1'
-
for merge and goto, if a $sha1 ends in a single quote, the - rewritten commit is substituted (if there is one).
-

- Example: -

-

-A - B - - - E 
-  \       /
-    C - D
-
-

- could yield this TODO script: -

-

-	pick A
-	pick C
-	pick D
-	goto A'
-	pick B
-	merge D' was E
-
-

- This should lead to a much more intuitive user experience. -

- I am very sorry if somebody actually scripted rebase -i -p (by setting - GIT_EDITOR with a script), but I am very certain that this cleanup is - absolutely necessary to make rebase -i -p useful. -

diff --git a/source-1233277286.txt b/source-1233277286.txt new file mode 100644 index 0000000000..4c5d7bd1de --- /dev/null +++ b/source-1233277286.txt @@ -0,0 +1,41 @@ +More valgrind fun + +So I spent quite a number of hours on that funny zlib/valgrind issue. The +thing is, zlib people claim that even if their code accesses uninitialized +memory, it does not produce erroneous data (by cutting out the results of the +uninitialized data, which is cheaper than checking for the end of the buffer +in an unaligned manner), so zlib will always be special for valgrind. + +However, the bug I was chasing is funny, and different from said issue. zlib +deflates an input buffer to an output buffer that is exactly 58 bytes long. +But valgrind claims that the 52nd of those bytes is uninitialized, and _only_ +that one. + +But it is not. It must be 0x2c, otherwise zlib refuses to inflate the +buffer. + +Now, I went into a debugging frenzy, and finally found out that zlib just +passes fine (with the default suppressions because of the "cute" way it +uses uninitialized memory), _except_ when it is compiled with UNALIGNED_OK +defined. + +Which Ubuntu does, of course. Ubuntu, the biggest forker of all. + +The bad part is that it sounds like a bug in valgrind, and I _could_ imagine +that it is an issue of an optimized memcpy() that copies int by int, and +that valgrind misses out on the fact that a part of that int is actually +_not_ uninitialized. + +But my debugging session's results disagree with that. + +With the help of Julian Seward, the original author of valgrind, I instrumented +zlib's source code so that valgrind checks earlier if the byte is initialized +or not, to find out where the reason of the issue lies. + +The sad part is that when I added the instrumentation to both the _end_ of +the while() loop in compress_block() in zlib's trees.c, and just _after_ the +while() loop (whose condition is a plain ''variable < variable'' comparison, +nothing fancy, certainly not changing any memory), only the _latter_ catches +a valgrind error. + +And that is truly strange. -- 2.11.4.GIT