git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Valgrind updates

From
Johannes Schindelin <johannes.schindelin@gmx.de>
Date
Jan 27, 2009, 04:46 UTC
Message-ID
<alpine.DEB.1.00.0901270544450.14855@racer>
In-Reply-To
<alpine.DEB.1.00.0901270512171.14855@racer>
Hi,
On Tue, 27 Jan 2009, Johannes Schindelin wrote:
Show 43 quoted lines
> On Mon, 26 Jan 2009, Linus Torvalds wrote:
> 
> > On Tue, 27 Jan 2009, Johannes Schindelin wrote:
> > > 
> > > Just that much, most of the backtraces are pretty repetitive.  In 
> > > fact, I think most if not all of them touch xwrite.c (I got other 
> > > errors from my patches, as I expected).
> > > 
> > > ==valgrind== Syscall param write(buf) points to uninitialised byte(s)
> > > ==valgrind==    at 0x5609E40: __write_nocancel (in /lib/libpthread-2.6.1.so)
> > > ==valgrind==    by 0x4D0380: xwrite (wrapper.c:129)
> > > ==valgrind==    by 0x4D046E: write_in_full (wrapper.c:159)
> > > ==valgrind==    by 0x4C0697: write_buffer (sha1_file.c:2275)
> > > ==valgrind==    by 0x4C0B1C: write_loose_object (sha1_file.c:2387)
> > 
> > Looks entirely bogus.
> 
> And it gets worse.
> 
> I suspected that zlib does something "cute" with alignments, i.e. that 
> it writes a possibly odd number of bytes, but then rounds up the buffer 
> to the next multiple of two of four bytes.
> 
> Yet, the buffer in question is 195 bytes, stream.total_count (which 
> totally agrees with size - stream.avail_out) says it is 58 bytes, and 
> valgrind says that the byte with offset 51 is uninitialized.
> 
> So it is definitely a zlib error.  And a strange one at that.  Even 
> allowing for a header, if we have 51 valid bytes in the buffer 
> (remember: the 52nd byte is reported uninitialized by valgrind), even on 
> a 64-bit machine, it should not be rounded up to 58 bytes reported by 
> zlib.  And the address of the buffer seems to be even 16-byte aligned 
> (that's probably valgrind's doing).
> 
> Just for bullocks, I let valgrind check if offset 51 is the only 
> uninitialized byte (who knows what zlib is thinking that it's doing?), 
> and here's the rub: offset 51 is indeed the _only_ one which valgrind 
> thinks is uninitialized!
> 
> Wasn't there some zlib wizard in the kernel community?  We could throw 
> that thing at him, to see why it behaves so strangely...
> 
> Of course, it could also be a valgrind issue, as you suggested.  Hmpf.
FWIW this test was done with 3.4.0.SVN.

Just to be sure, I upgraded to 3.5.0.SVN, the very newest update (well, as new as I could make my git svn mirror of valgrind and VEX deliver). Still there.

Off to bed, Dscho

Previous: Johannes SchindelinNext: Mark Brown
Message 53 of 73 in “What's cooking in git.git (Jan 2009, #04; Mon, 19)”
  1. Junio C HamanoJan 19, 2009
  2. Kjetil BarvikJan 19, 2009
  3. Johannes SchindelinJan 19, 2009
  4. Johannes SchindelinJan 19, 2009
  5. Jeff KingJan 20, 2009
  6. valgrind patches, was Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)Johannes Schindelin, Jan 20, 2009
  7. Jeff KingJan 20, 2009
  8. Johannes SchindelinJan 20, 2009
  9. 1/2 Add valgrind support in test scriptsJohannes Schindelin, Jan 20, 2009
  10. 2/2 valgrind: ignore ldso errorsJohannes Schindelin, Jan 20, 2009
  11. Jeff KingJan 21, 2009
  12. Johannes SchindelinJan 21, 2009
  13. 1/2 Add valgrind support in test scriptsJohannes Schindelin, Jan 21, 2009
  14. 1/2 Add valgrind support in test scriptsJohannes Schindelin, Jan 21, 2009
  15. Junio C HamanoJan 21, 2009
  16. Johannes SchindelinJan 21, 2009
  17. Jeff KingJan 21, 2009
  18. Johannes SchindelinJan 21, 2009
  19. Jeff KingJan 21, 2009
  20. Johannes SchindelinJan 21, 2009
  21. 0/3 Valgrind supportJohannes Schindelin, Jan 25, 2009
  22. 1/3 Add valgrind support in test scriptsJohannes Schindelin, Jan 25, 2009
  23. Jeff KingJan 25, 2009
  24. Johannes SchindelinJan 25, 2009
  25. Jeff KingJan 25, 2009
  26. 2/3 valgrind: ignore ldso and more libz errorsJohannes Schindelin, Jan 25, 2009
  27. Jeff KingJan 25, 2009
  28. Johannes SchindelinJan 26, 2009
  29. Jeff KingJan 26, 2009
  30. 3/3 Valgrind support: check for more than just programming errorsJohannes Schindelin, Jan 25, 2009
  31. Jeff KingJan 25, 2009
  32. Johannes SchindelinJan 26, 2009
  33. valgrind tests: be super-super paranoid when creating symlinksJohannes Schindelin, Jan 21, 2009
  34. Jeff KingJan 20, 2009
  35. Johannes SchindelinJan 21, 2009
  36. Jeff KingJan 21, 2009
  37. Johannes SchindelinJan 21, 2009
  38. Jeff KingJan 21, 2009
  39. Johannes SchindelinJan 21, 2009
  40. 2/2 valgrind: ignore ldso errorsJohannes Schindelin, Jan 21, 2009
  41. Jeff KingJan 21, 2009
  42. Johannes SchindelinJan 21, 2009
  43. Jeff KingJan 21, 2009
  44. Johannes SchindelinJan 21, 2009
  45. Jeff KingJan 21, 2009
  46. Junio C HamanoJan 22, 2009
  47. Jeff KingJan 22, 2009
  48. Johannes SchindelinJan 22, 2009
  49. Jeff KingJan 22, 2009
  50. Valgrind updatesJohannes Schindelin, Jan 27, 2009
  51. Linus TorvaldsJan 27, 2009
  52. Johannes SchindelinJan 27, 2009
  53. Johannes SchindelinJan 27, 2009
  54. Mark BrownJan 27, 2009
  55. Johannes SchindelinJan 27, 2009
  56. Linus TorvaldsJan 27, 2009
  57. Johannes SchindelinJan 27, 2009
  58. Linus TorvaldsJan 29, 2009
  59. Johannes SchindelinJan 29, 2009
  60. Mark AdlerJan 28, 2009
  61. Johannes SchindelinJan 28, 2009
  62. Mark AdlerJan 29, 2009
  63. Johannes SchindelinJan 29, 2009
  64. Johannes SchindelinJan 29, 2009
  65. Jeff KingJan 27, 2009
  66. Johannes SchindelinJan 27, 2009
  67. Jeff KingJan 20, 2009
  68. Jeff KingJan 20, 2009
  69. Junio C HamanoJan 20, 2009
  70. Johannes SixtJan 20, 2009
  71. Jeff KingJan 20, 2009
  72. Boyd Stephen Smith Jr.Jan 20, 2009
  73. Thomas RastJan 20, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.