Running with valgrind gives a bunch of errors : Conditional jump or move depends on uninitialised value(s)

[GoogleCodeExporter]

I want to detect memory leak or bad memory access with my program, and I
get a LOT of errors with valgrind, coming from googletest. Most of the
errors are of the type :
Conditional jump or move depends on uninitialised value(s)

Attached is the output from running
valgrind --tool=memcheck --show-reachable=yes --leak-check=yes ./myexec

GoogleTest does not seem to be compatible with valgrind, which is kind of
lame, since these are two tools meant for debugging.

Original issue reported on code.google.com by communic...@usherbrooke.ca on 5 Feb 2009 at 4:10

Attachments:

• valgrind.out

[GoogleCodeExporter]

Original comment by zhanyong...@gmail.com on 6 Feb 2009 at 6:21

• Changed state: Accepted
• Added labels: OpSys-All, Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

I'm not a valgrind power user, but from the report, it seems that the errors 
mostly
come from strlen(), not gtest.  I also know many people using valgrind and gtest
together with no problem.

Could it be that the strlen() implementation on your system is triggering the 
errors?
 Could you do some experiments to find out?  Also, which version of valgrind and
which version of gtest are you using?

Original comment by zhanyong...@gmail.com on 6 Feb 2009 at 6:55

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Hello,
I have tested again, and most of the code seems to be fine now.
I only get one last error :
==15660== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 5 from 1)
==15660== malloc/free: in use at exit: 755,788 bytes in 1 blocks.
==15660== malloc/free: 13,946 allocs, 13,945 frees, 2,877,001 bytes allocated.
==15660== For counts of detected errors, rerun with: -v
==15660== searching for pointers to 1 not-freed blocks.
==15660== checked 1,018,528 bytes.
==15660== 
==15660== 755,788 bytes in 1 blocks are still reachable in loss record 1 of 1
==15660==    at 0x4A04B32: calloc (vg_replace_malloc.c:279)
==15660==    by 0x3BF50D397F: monstartup (in /lib64/libc-2.5.so)
==15660==    by 0x40253B: __gmon_start__ (in
/home/mboisson/svn/Codes/SQUACK/gtests/gtest_all.out)
==15660==    by 0x3BFAE01E61: (within /lib64/libgcc_s-4.1.2-20080102.so.1)
==15660== 
==15660== LEAK SUMMARY:
==15660==    definitely lost: 0 bytes in 0 blocks.
==15660==      possibly lost: 0 bytes in 0 blocks.
==15660==    still reachable: 755,788 bytes in 1 blocks.
==15660==         suppressed: 0 bytes in 0 blocks.

Many things have changed in my setup. The administrator has reinstalled gtest.

Original comment by mboi...@gmail.com on 4 Mar 2009 at 6:55

[GoogleCodeExporter]

What's the type of the object that was not released?

Original comment by zhanyong...@gmail.com on 4 Mar 2009 at 7:01

[GoogleCodeExporter]

I can't know, ii s in compiled code. I'm not even sure this has to do with gtest
anymore. I understand this is not really helpfull. All I know is that it is not 
in
the code that I am compiling.

I guess this "bug" can be dropped.

Original comment by mboi...@gmail.com on 4 Mar 2009 at 7:09

[GoogleCodeExporter]

Closing as the user suggested.

Original comment by zhanyong...@gmail.com on 4 Mar 2009 at 7:20

• Changed state: Invalid

[GoogleCodeExporter]

Hi,

I think this issue needs to be reopened. Indeed, the "Conditional jump or move
depends on uninitialised value(s)" errors appear as soon as you link with 
googletest,
even if you don't use it at all!

Here's how to reproduce:
Environment: Red Hat on x86_64 architecture
Compiler: g++ (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44)
Gtest: I found no way of display the exact gtest version, but it was downloaded 
on
December 1st I believe.

Create a file gtestBug.C containing:
-----------------------------------------
int main(int argc, char* argv[])
{
    return 0;
}
-----------------------------------------

Then, compile with linking to googletest:
g++ -g -O0 -ansi -Wall -W -c gtestBug.C
g++ -g -O0 -o gtestBug gtestBug.o -static -L/usr/local/lib -lgtest

Finally, run "valgrind gtestBug". Here's my output:
------------------------------------------
==28233== Memcheck, a memory error detector.
==28233== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==28233== Using LibVEX rev 1658, a library for dynamic binary translation.
==28233== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==28233== Using valgrind-3.2.1, a dynamic binary instrumentation framework.
==28233== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==28233== For more details, rerun with: -v
==28233==
==28233== Conditional jump or move depends on uninitialised value(s)
==28233==    at 0x41580D: strlen (in /XXXXX/gtestBug)
==28233==    by 0x433CC4: fillin_rpath (in /XXXXX/gtestBug)
==28233==    by 0x4359F5: _dl_init_paths (in /XXXXX/gtestBug)
==28233==    by 0x4196BE: _dl_non_dynamic_init (in /XXXXX/gtestBug)
==28233==    by 0x419F8A: __libc_init_first (in /XXXXX/gtestBug)
==28233==    by 0x40A59C: (below main) (in /XXXXX/gtestBug)
==28233==
==28233== Use of uninitialised value of size 8
==28233==    at 0x40B003: exit (in /XXXXX/gtestBug)
==28233==
==28233== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
==28233== malloc/free: in use at exit: 0 bytes in 0 blocks.
==28233== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==28233== For counts of detected errors, rerun with: -v
==28233== All heap blocks were freed -- no leaks are possible.
--------------------------------------------------

The error disappears if I don't link with gtest, so the problem seems to be 
from some
static initialization performed by gtest.

Note that the version of gcc I pointed too was the one used to compile the tiny
program above. I wouldn't swear gtest itlesf was compiled with the same version.

Original comment by mercier....@gmail.com on 10 Dec 2009 at 5:59

[GoogleCodeExporter]

Original comment by w...@google.com on 17 Dec 2009 at 5:41

• Changed state: Accepted

[GoogleCodeExporter]

The error comes from strlen(), a standard libc function.

I suspect it's caused by compiling gtest and your test using different compiler
versions/settings.  I recommend to compile your own gtest library with the same
compiler settings as you use to compile your test, instead of using the 
installed gtest.

Original comment by w...@google.com on 23 Dec 2009 at 5:58

• Changed state: Invalid