Hi,

This issue is observed in a real-world example of trying to debug 
memory-related issues of mozilla thunderbird mail client.

As far as the program was concerned, these warnings are generated that a certain length of memory copy (length=31 is a clear indication) [and particular
memory layout] seems to trigger this warning.
Since there have been these false positives (noted above) [or maybe the
substituded memcpy during valgrind run DOES HAVE  the memory issue.],
it is quite annoying to see many of these warnings somehow.

I am trying to see if there is a similar bug report in Debian ( or anywhere else. I notice similar ones date a couple of years ago or older [some of them were reported to be fixed.], but not recent one.)

Any pointers on this issue will be appreciated.

Excerpt from a session log: (the line numbers may be off from the pristine copy
of TB (comm-central) version due to local modification.
(Recorded during debugging the issue reported in
https://bugzilla.mozilla.org/show_bug.cgi?id=814870
Bug 814870 - Invalid read of size 1 in PR_ParseTimeStringToExplodedTime (prtime.c:1450))


date->length=31

==24420== Invalid read of size 8

==24420==    at 0x42B719F: __bcopy_ssse3 (memcpy-ssse3.S:720)

==24420==    by 0xA67585C: nsParseMailMessageState::ParseFolderLine(char const*, unsigned int) (nsParseMailbox.cpp:714)

==24420==    by 0xA6699A0: nsMsgMailboxParser::HandleLine(char*, unsigned int) (nsParseMailbox.cpp:518)

==24420==    by 0xA4D52F0: nsMsgLineBuffer::ConvertAndSendBuffer() (nsMsgLineBuffer.cpp:233)
  ...

(In reply to comment #0)
> If I compile and run the program below and run it under valgrind, I got the
> following error shown below. 

I can't reproduce this, using your test program, Valgrind SVN trunk,
"gcc (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2)" on Fedora 17.  Can you
reproduce it using the Valgrind SVN trunk?

(2013/01/21 20:23), Julian Seward wrote:
> https://bugs.kde.org/show_bug.cgi?id=311407
>
> --- Comment #2 from Julian Seward <jseward@acm.org> ---
> (In reply to comment #0)
>> If I compile and run the program below and run it under valgrind, I got the
>> following error shown below.
>
> I can't reproduce this, using your test program, Valgrind SVN trunk,
> "gcc (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2)" on Fedora 17.  Can you
> reproduce it using the Valgrind SVN trunk?
>

Dear Julian,

Thank you for your message.

OK, I will check the operation using SVN version.

Best Regards,
Chiaki

This is again observed with valgrind SVN version under 32-bit version of Debian GNU/linux.

System info is
$ uname -a
Linux debian-vm 3.2.0-4-686-pae #1 SMP Debian 3.2.32-1 i686 GNU/Linux
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i486-linux-gnu/4.7/lto-wrapper
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-4' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-targets=all --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.7.2 (Debian 4.7.2-4) 
$ 

/tmp/a.out is the compiled version of the sample program.

ishikawa@debian-vm:/tmp$ valgrind /tmp/a.out
==32715== Memcheck, a memory error detector
==32715== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==32715== Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright info
==32715== Command: /tmp/a.out
==32715== 
i, j, k = 0, 246, 0
i, j, k = 0, 246, 1
==32715== Invalid read of size 8
==32715==    at 0x416D579: __bcopy_ssse3 (memcpy-ssse3.S:1026)
==32715==    by 0x4064E45: (below main) (libc-start.c:228)
==32715==  Address 0x41b3300 is 8 bytes before a block of size 318 alloc'd
==32715==    at 0x4027388: malloc (vg_replace_malloc.c:270)
==32715==    by 0x80485EC: main (test-copy-2.c:22)
==32715== 
i, j, k = 0, 246, 2
==32715== Invalid read of size 8
==32715==    at 0x416D4E9: __bcopy_ssse3 (memcpy-ssse3.S:981)
==32715==    by 0x4064E45: (below main) (libc-start.c:228)
==32715==  Address 0x41b35e0 is 8 bytes before a block of size 318 alloc'd
==32715==    at 0x4027388: malloc (vg_replace_malloc.c:270)
==32715==    by 0x80485EC: main (test-copy-2.c:22)
==32715== 
i, j, k = 0, 246, 3
==32715== Invalid read of size 8
==32715==    at 0x416D459: __bcopy_ssse3 (memcpy-ssse3.S:936)
==32715==    by 0x4064E45: (below main) (libc-start.c:228)
==32715==  Address 0x41b38c0 is 8 bytes before a block of size 318 alloc'd
==32715==    at 0x4027388: malloc (vg_replace_malloc.c:270)
==32715==    by 0x80485EC: main (test-copy-2.c:22)
==32715== 
i, j, k = 0, 246, 4
==32715== Invalid read of size 8
==32715==    at 0x416D3C9: __bcopy_ssse3 (memcpy-ssse3.S:891)
==32715==    by 0x4064E45: (below main) (libc-start.c:228)
==32715==  Address 0x41b3ba0 is 8 bytes before a block of size 318 alloc'd
==32715==    at 0x4027388: malloc (vg_replace_malloc.c:270)
==32715==    by 0x80485EC: main (test-copy-2.c:22)
==32715== 
i, j, k = 0, 246, 5
==32715== Invalid read of size 8
==32715==    at 0x416D339: __bcopy_ssse3 (memcpy-ssse3.S:846)
==32715==    by 0x4064E45: (below main) (libc-start.c:228)
==32715==  Address 0x41b3e80 is 8 bytes before a block of size 318 alloc'd
==32715==    at 0x4027388: malloc (vg_replace_malloc.c:270)
==32715==    by 0x80485EC: main (test-copy-2.c:22)
==32715== 
i, j, k = 0, 246, 6
==32715== Invalid read of size 8
==32715==    at 0x416D2A9: __bcopy_ssse3 (memcpy-ssse3.S:801)
==32715==    by 0x4064E45: (below main) (libc-start.c:228)
==32715==  Address 0x41b4160 is 8 bytes before a block of size 318 alloc'd
==32715==    at 0x4027388: malloc (vg_replace_malloc.c:270)
==32715==    by 0x80485EC: main (test-copy-2.c:22)
==32715== 
i, j, k = 0, 246, 7
==32715== Invalid read of size 8
==32715==    at 0x416D219: __bcopy_ssse3 (memcpy-ssse3.S:756)
==32715==    by 0x4064E45: (below main) (libc-start.c:228)
==32715==  Address 0x41b4440 is 8 bytes before a block of size 318 alloc'd
==32715==    at 0x4027388: malloc (vg_replace_malloc.c:270)
==32715==    by 0x80485EC: main (test-copy-2.c:22)
==32715== 
i, j, k = 0, 246, 8
i, j, k = 0, 246, 9
i, j, k = 0, 246, 10
i, j, k = 0, 246, 11
i, j, k = 0, 246, 12
i, j, k = 0, 246, 13
i, j, k = 0, 246, 14
 ...
i, j, k = 32, 278, 22
i, j, k = 32, 278, 23
==32715== 
==32715== HEAP SUMMARY:
==32715==     in use at exit: 0 bytes in 0 blocks
==32715==   total heap usage: 52,272 allocs, 52,272 frees, 17,458,848 bytes allocated
==32715== 
==32715== All heap blocks were freed -- no leaks are possible
==32715== 
==32715== For counts of detected and suppressed errors, rerun with: -v
==32715== ERROR SUMMARY: 1176 errors from 7 contexts (suppressed: 11 from 6)

I have no idea, but only differences of your environment and mine I can think of
are 
 - I am using 32 bits version of Debian GNU/Linux, and
 - Debian seems to use a so called embedded libc (derived from GNU libc).

I wonder if the memcpy.-ssse3S is from valgrind/memcheck or Debian's libc.
Debian 32bit libc  may not contain a proper fix for the type of problems earlier reported in
https://bugzilla.redhat.com/show_bug.cgi?id=705790

I also found a reference about overeager reading of some library routines in
http://code.google.com/p/chromium/issues/detail?id=58730

I don't think just hiding this under the rug using suppression as suggested
in the above article is good because
such eager reading CAN end in an invalid memory access and segfault if the program is looking at the upper end of the user area allocated by sbrk()/brk()(unless the library checks for this condition by comparing sbrk() value and takes proper precaution not to overstep.)

I wonder which version of memcopy-ssse3.S is used after all.

TIA

I can reproduce this when compiled for 32 bits on Fedora, but not when compiled for 64 bits.

Fix committed as r13253.

(In reply to comment #6)
> Fix committed as r13253.

Thank you! I pulled the SVN source tree and I no longer see the problem.

Well, the patch seemed to fix the particular problem noticed by the
test program posted here.

Is there any chance that the patch missed off-by-one error?

I now get the following error message from memcheck during of debugging
of TB and not quite sure if I should believe the message to be correct or not :-(
[At least now I notice that bcopy is replaced with a mc_replace_strmem.c version.]

date->length=31
==2958== Invalid read of size 1
==2958==    at 0x402A450: bcopy (mc_replace_strmem.c:1106)
==2958==    by 0xA67469B: nsParseMailMessageState::FinalizeHeaders() (nsParseMailbox.cpp:1674)

	    [...]

==2958==    by 0xB62B76E: js::CallJSNative(JSContext*, int (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) (jscntxtinlines.h:373)
==2958==  Address 0x700483f is 1 bytes before a block of size 204 alloc'd
==2958==    at 0x40273B8: malloc (vg_replace_malloc.c:270)
==2958==    by 0x404BE13: moz_xmalloc (mozalloc.cpp:54)
==2958==    by 0xADF42C3: NS_Alloc_P (nsMemoryImpl.cpp:198)

So maybe the bug of invalid read of one byte is for real, but I just wanted to
be sure since the fix is very new and maybe I thought there can be
a subtle bug in valgrind memcpy version.

TIA

Sorry, I think the previous waring is for real.
There was a bug in my data dumping code that seems to refer to the uninitialized data area. Sorry for the noise.

TIA