Good day -
Please could anyone explain why valgrind v3.13.0, built for x86_64 under Linux
(RHEL 7.4), is complaining about
"Conditional jump or move depends on uninitialised value(s)"
in this case - I cannot see how any memory accessed by this
code is uninitialized, and inspecting the V bits and shadow
registers also does not show any 0 bits - the program always
stops with the above error, at the line
==26770== Thread 4:
==26770== Conditional jump or move depends on uninitialised value(s)
==26770== at 0x5C3EF46: lround (s_llround.c:42)
which is entered via the line in our code:
const uint32_t delta_time = uint32_t(std::lround(sensor.time * 2e9));
^^^^^^^^^^^^^^^^^^^^^^^^
This is a call to GLIBC v2.17's lround, in glibc source code file:
sysdeps/ieee754/dbl-64/wordsize-64/s_llround.c,
@ line 28:
long long int
__llround (double x)
{ // I recompiled glibc to add initializers for
// these auto variables, but it made no difference:
int32_t j0=0;
int64_t i0=0;
long long int result=0;
int sign=0;
EXTRACT_WORDS64 (i0, x);
j0 = ((i0 >> 52) & 0x7ff) - 0x3ff;
sign = i0 < 0 ? -1 : 1;
i0 &= UINT64_C(0xfffffffffffff);
i0 |= UINT64_C(0x10000000000000);
@ line 42:
==> if (j0 < (int32_t) (8 * sizeof (long long int)) - 1)
{
EXTRACT_WORDS64 resolves to an asm statement defined in
sysdeps/x86_64/fpu/math_private.h:
/* Direct movement of float into integer register. */
#define EXTRACT_WORDS64(i, d)
\
do {
\
int64_t i_;
\
asm (MOVD " %1, %0" : "=rm" (i_) : "x" ((double) (d)));
\
(i) = i_;
\
} while (0)
.
When I run valgrind with options:
--tool=memcheck --track-origins=yes --vgdb-shadow-registers=yes
--vgdb=yes \
--vgdb-error=0 my_program ....
it invariably stops at the same s_llround.c:42 place shown above .
Inspecting the valid bits for both 'j0' (in glibc's __llround) and 'sensor.time'
(in our code) in GDB shows ALL VALID BITS set :
(gdb is stopped at s_llround.c, line 42):
(gdb) p &j0
Address requested for identifier "j0" which is in register $rdx
(gdb) p/x $rdxs1
$1 = 0xffffffff
(gdb) p j0
$1 = 6
// so the j0 variable appears to be valid, according to valgrind's
shadow register V-bits.
// So why did valgrind stop at that particular line, where no variable
or memory other
// than j0 is being accessed ?
(gdb) up
... ( back to our code: delta_time =
uint32_t(std::lround(sensor.time * 2e9));
... sensor is a structure reference variable
... )
(gdb) p &sensor->time
$16 = (double *) 0x10ea9088
(gdb) mo xb 0x10ea9088 8
ff ff ff ff ff ff ff ff
0x10EA9088: 0xef 0xd9 0x0e 0x32 0x57 0x0e 0x6a 0x3e
So how can I tell which valid bit valgrind is complaining about being 0 here ?
No relevant valid bits appear to be 0 ?
Yes, not all bits for the whole 40 byte 'sensor' structure are valid
yet (it is in the processof being constructed here) but the 8 bytes
referenced by 'sensor.time' ARE VALID , and no other bits can be
accessed by the statement at which valgrind stops.
It just says at the end:
==26770== Uninitialised value was created by a stack allocation
==26770== at 0x4E2979: main (Main.cpp:88)
Yes, the 'sensor' structure is part of a 200MB array created at
program initialization , which is populated by SPI + GPIO + DMA reads
from an embedded device, in the multi-threaded program. But the memory
being accessed by the statement above HAS ALL VALID BITS SET, so I
cannot see what valgrind is complaining about here .
I'd really appreciate some kind of '--show-valid-bits-and-addresses'
option to valgrind, which would make it display exactly the valid bits
it found to be 0, and which memory addresses / registers they
correspond to .
I believe the above behavior represents a BUG in latest version of
valgrind, because
NO RELEVANT VALID BITS ARE ZERO , AFAICS.
valgrind-3.12.0 (the RHEL-7.4 default version) displays the same behavior , and
stops at the same place with the same error.
I'd really like to test our program with valgrind, but false positives such as
the above are blocking this - I am having to abandon valgrind testing because of
this issue , because valgrind appears to be too buggy to use. The program runs
fine outside of valgrind without any errors (usually) - but as I am changing it
I'd like to run it under valgrind as part of standard automated testing.
Any ideas / suggestions how to resolve this false positive, or proof that it is
not a false positive, would be most gratefully received.
Thanks in advance & Best Regards .
Jason Vas Dias
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
