Need to fix valgrind issue in tcmalloc.so

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Build perftools
2. From the build directory run: 
valgrind --tool=memcheck .libs/tcmalloc_unittest
3. Observe the error:
==25695== Invalid write of size 4
==25695==    at 0x2F1A7: tcmalloc::CentralFreeList::Populate() (in
/usr/local/lib/libtcmalloc.so.0)
==25695==    by 0x2F2E7: tcmalloc::CentralFreeList::FetchFromSpansSafe()
(in /usr/local/lib/libtcmalloc.so.0)
==25695==    by 0x2F35A: tcmalloc::CentralFreeList::RemoveRange(void**,
void**, int) (in /usr/local/lib/libtcmalloc.so.0)
==25695==    by 0x310FB:
tcmalloc::ThreadCache::FetchFromCentralCache(unsigned, unsigned) (in
/usr/local/lib/libtcmalloc.so.0)
==25695==    by 0x4BAF4: malloc (in /usr/local/lib/libtcmalloc.so.0)
==25695==    by 0x8049B10: TestAlignmentForSize(int) (tcmalloc_unittest.cc:690)
==25695==    by 0x8049C43: TestMallocAlignment() (tcmalloc_unittest.cc:707)
==25695==    by 0x804AED2: main (tcmalloc_unittest.cc:888)
==25695==  Address 0x81D1000 is not stack'd, malloc'd or (recently) free'd

What is the expected output? What do you see instead?
expected no errors

What version of the product are you using? On what operating system?
1.0

Please provide any additional information below.
Please run all available testcases under valgrind memcheck and fix all
issues like this if found.

Original issue reported on code.google.com by visa_des...@yahoo.com on 20 Jan 2009 at 1:34

[GoogleCodeExporter]

Does valgrind check for memory that was allocated via sbrk?  Overall, I wouldn't
expect valgrind to work so well with a low-level library like tcmalloc.  
(Though I
could be wrong.)  I don't really have any intention of making tcmalloc
valgrind-clean, but I'll keep this bug open to look into where the problem is 
here --
in tcmalloc, valgrind, or something else -- if I have a free moment.

Original comment by csilv...@gmail.com on 21 Jan 2009 at 12:08

[GoogleCodeExporter]

I believe valgrind checks for memory allocated by sbrk because otherwise it 
would 
flag all such memory as problematic.

Many companies run valgrind as a routine to check cleanliness of their projects 
and 
if they use tcmalloc this issue will come up every time.

On the side note vg maybe shouldn't even go below malloc/free level, but for 
some 
reason it goes there.

I don'e think it will hurt too much to fix it.

Original comment by visa_des...@yahoo.com on 27 Jan 2009 at 8:41

[GoogleCodeExporter]

I had a chance to look into this today, and could not reproduce the problem on 
my
local machine (ubuntu 6 or so, using gcc 4.0.3).  I ran valgrind on 
tcmalloc_unittest
and got various memory leak reports, but no error message.

Possibly this is an issue only on some architectures, or some versions of gcc, 
or
some versions of valgrind?  I'm afraid it will be hard for me to debug this 
without
being able to reproduce it.

Original comment by csilv...@gmail.com on 30 Jan 2009 at 1:24

[GoogleCodeExporter]

I'm still unable to reproduce the error, so unless you can give me at least 
more info
-- what OS and compiler you found this on -- I will have to close the bug as
CannotReproduce.

Original comment by csilv...@gmail.com on 6 Mar 2009 at 8:29

[GoogleCodeExporter]

Original comment by csilv...@gmail.com on 6 Mar 2009 at 8:30

• Added labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

Ok, it's been a while now with no new info, so I'm closing this 
CannotReproduce. 
Feel free to reopen it if you can provide more data.

Original comment by csilv...@gmail.com on 14 Oct 2009 at 11:12

• Changed state: CannotReproduce

[GoogleCodeExporter]

I'm getting the same error in Fedora-19 x64 (gperftools version 2.1-1.fc19).
I also remember I occasionally saw it a few years ago. Probably that was 
Fedora, too.

valgrind output below:

==14251== 
==14251== HEAP SUMMARY:
==14251==     in use at exit: 0 bytes in 0 blocks
==14251==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==14251== 
==14251== All heap blocks were freed -- no leaks are possible
==14251== 
==14251== Use --track-origins=yes to see where uninitialised values come from
==14251== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
==14251== 
==14251== 1 errors in context 1 of 1:
==14251== Syscall param msync(start) points to uninitialised byte(s)
==14251==    at 0x3AE4C0E780: __msync_nocancel (in 
/usr/lib64/libpthread-2.17.so)
==14251==    by 0x3AE7802E43: ??? (in /usr/lib64/libunwind.so.8.0.1)
==14251==    by 0x3AE7805C26: ??? (in /usr/lib64/libunwind.so.8.0.1)
==14251==    by 0x3AE7806E81: ??? (in /usr/lib64/libunwind.so.8.0.1)
==14251==    by 0x3AE7807228: ??? (in /usr/lib64/libunwind.so.8.0.1)
==14251==    by 0x3AE7803750: _ULx86_64_step (in /usr/lib64/libunwind.so.8.0.1)
==14251==    by 0x4C357A2: GetStackTrace(void**, int, int) (in 
/usr/lib64/libprofiler.so.0.3.2)
==14251==    by 0x4E66C6B: tcmalloc::PageHeap::GrowHeap(unsigned long) (in 
/usr/lib64/libtcmalloc.so.4.1.2)
==14251==    by 0x4E66F82: tcmalloc::PageHeap::New(unsigned long) (in 
/usr/lib64/libtcmalloc.so.4.1.2)
==14251==    by 0x4E65AD6: tcmalloc::CentralFreeList::Populate() (in 
/usr/lib64/libtcmalloc.so.4.1.2)
==14251==    by 0x4E65CA7: tcmalloc::CentralFreeList::FetchFromSpansSafe() (in 
/usr/lib64/libtcmalloc.so.4.1.2)
==14251==    by 0x4E65D22: tcmalloc::CentralFreeList::RemoveRange(void**, 
void**, int) (in /usr/lib64/libtcmalloc.so.4.1.2)
==14251==  Address 0x7fefff0e0 is on thread 1's stack
==14251== 
--14251-- 
--14251-- used_suppression:      2 glibc-2.5.x-on-SUSE-10.2-(PPC)-2a
==14251== 
==14251== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)

Original comment by hideaki.kimura@gmail.com on 8 Mar 2014 at 8:58

[GoogleCodeExporter]

That's pointing at some issue in libunwind.

Original comment by alkondratenko on 10 Mar 2014 at 4:58