Hi,
I have the following code, for which valgrind reports an error, altho=
ugh
it is perfectly valid:
used=3D0;
if (i<N || dist<best_dist[N-1])
{
//Error reported=20
for (k=3DN-1; (k >=3D 1) && (k > used || dist < best_dist[k-1]); k=
--)
{
best_dist[k]=3Dbest_dist[k-1];
nbest[k] =3D nbest[k-1];
}
best_dist[k]=3Ddist;
nbest[k]=3Di;
used++;
}
what seems to be causing the problem is that best_dist is not
initialized. However initialization should not be necessary because t=
he
part before the ||
=09Jean-Marc
--=20
Jean-Marc Valin <Jean-Marc.Valin@USherbrooke.ca>
Universit=E9 de Sherbrooke
|
|
From: Dennis L. <pla...@in...> - 2005-03-03 11:10:37
|
Am Donnerstag, den 03.03.2005, 04:22 -0500 schrieb Jean-Marc Valin:
> Hi,
>
> I have the following code, for which valgrind reports an error, although
> it is perfectly valid:
>
> used=0;
> if (i<N || dist<best_dist[N-1])
> {
> //Error reported
> for (k=N-1; (k >= 1) && (k > used || dist < best_dist[k-1]); k--)
> {
> best_dist[k]=best_dist[k-1];
> nbest[k] = nbest[k-1];
> }
> best_dist[k]=dist;
> nbest[k]=i;
> used++;
> }
>
> what seems to be causing the problem is that best_dist is not
> initialized. However initialization should not be necessary because the
> part before the ||
>
> Jean-Marc
Since we dont know what types the variables are, and what values they
have, and in which case valgrind reports an error, we cannot say much to
this case. We can see more if you give us an example, which we can
compile, link and run without modifying it.
greets
Dennis
|
|
From: Jean-Marc V.
Attachments:
val.c
|
Hi,
I'm attaching a program that demonstrates the problem. When I compile
with -O0 or -O1, there's no problem, but with -O2 and above, I get:
% /opt/valgrind-2.2/bin/valgrind --tool=3Dmemcheck ./val
=3D=3D9257=3D=3D Memcheck, a memory error detector for x86-linux.
=3D=3D9257=3D=3D Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward=
et al.
=3D=3D9257=3D=3D Using valgrind-2.2.0, a program supervision framework fo=
r
x86-linux.
=3D=3D9257=3D=3D Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward=
et al.
=3D=3D9257=3D=3D For more details, rerun with: -v
=3D=3D9257=3D=3D
=3D=3D9257=3D=3D Use of uninitialised value of size 4
=3D=3D9257=3D=3D at 0x8048419: main (in /home/jm/val)
=3D=3D9257=3D=3D
=3D=3D9257=3D=3D Use of uninitialised value of size 4
=3D=3D9257=3D=3D at 0x8048490: main (in /home/jm/val)
0.000000 1.000000 2.000000 3.000000 4.000000 5.000000 6.000000 7.000000
8.000000 9.000000
=3D=3D9257=3D=3D
=3D=3D9257=3D=3D ERROR SUMMARY: 9 errors from 2 contexts (suppressed: 11 =
from 1)
=3D=3D9257=3D=3D malloc/free: in use at exit: 0 bytes in 0 blocks.
=3D=3D9257=3D=3D malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
=3D=3D9257=3D=3D For a detailed leak analysis, rerun with: --leak-check=3D=
yes
=3D=3D9257=3D=3D For counts of detected errors, rerun with: -v
Jean-Marc
P.S. I'm not on the list, so please CC to me.
Le jeudi 03 mars 2005 =E0 04:22 -0500, Jean-Marc Valin a =E9crit :
> Hi,
>=20
> I have the following code, for which valgrind reports an error, althoug=
h
> it is perfectly valid:
>=20
> used=3D0;
> if (i<N || dist<best_dist[N-1])
> {
> //Error reported=20
> for (k=3DN-1; (k >=3D 1) && (k > used || dist < best_dist[k-1]); k--=
)
> {
> best_dist[k]=3Dbest_dist[k-1];
> nbest[k] =3D nbest[k-1];
> }
> best_dist[k]=3Ddist;
> nbest[k]=3Di;
> used++;
> }
>=20
> what seems to be causing the problem is that best_dist is not
> initialized. However initialization should not be necessary because the
> part before the ||
>=20
> Jean-Marc
--=20
Jean-Marc Valin <Jean-Marc.Valin@USherbrooke.ca>
Universite de Sherbrooke
|
|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2005-03-04 09:29:56
Attachments:
val.c
|
Hi, > I'm attaching a program that demonstrates the problem. When I compile Mmmh... If the code was less obfuscated, maybe I could understand it :-) Seriously, can't the algorithm be clarified and the code simplified and properly indented? > with -O0 or -O1, there's no problem, but with -O2 and above, I get: I've added a few printf's to your code to track best_dist[k] initializations. It does look like best_dist[k] is initialized using unitialiazed best_dist[k-1] values. See attached modified val.c source file. Dimitri |
Hi, Perhaps I should explain what the code does. It's taken from the Spee= x ( http://www.speex.org/ ) codec. What it does is that in the real cod= e, the value of dist is the distance in a vector quantizer. The idea is = to compute the N smallest distance best_dist. It's normal that in the fi= rst few iterations, uninitialized values are moved around in best_dist, b= ut in the end, they are guarantied to be all gone and nothing ever depen= ds on these uninitialized values. =09Jean-Marc Le vendredi 04 mars 2005 =E0 10:29 +0100, Dimitri Papadopoulos-Orfano= s a =E9crit : > Hi, >=20 > > I'm attaching a program that demonstrates the problem. When I com= pile >=20 > Mmmh... If the code was less obfuscated, maybe I could understand i= t :-)=20 > Seriously, can't the algorithm be clarified and the code simplified= and=20 > properly indented? >=20 > > with -O0 or -O1, there's no problem, but with -O2 and above, I ge= t: >=20 > I've added a few printf's to your code to track best_dist[k]=20 > initializations. It does look like best_dist[k] is initialized usin= g=20 > unitialiazed best_dist[k-1] values. See attached modified val.c sou= rce file. >=20 > Dimitri --=20 Jean-Marc Valin <Jean-Marc.Valin@USherbrooke.ca> Universit=E9 de Sherbrooke |
|
From: Olly B. <ol...@su...> - 2005-03-04 20:20:55
|
On 2005-03-04, Jean-Marc Valin <Jean-Marc.Valin@USherbrooke.ca> wrote:
> It's normal that in the first
> few iterations, uninitialized values are moved around in best_dist, but
> in the end, they are guarantied to be all gone and nothing ever depends
> on these uninitialized values.
This is your problem then. For floating point values, valgrind issues
an error when reading an uninitialised value from memory (for integer
values, the error isn't issued until the uninitialised value can affect
control flow or is passed to a system call, because the assembler code
compilers generate often copies around uninitialised integer values -
for example when copying a structure including uninitialised padding
bytes).
You should be able to generate a suppression for this case if you're
happy it's safe to ignore this.
Cheers,
Olly
|
|
From: Nicholas N. <nj...@cs...> - 2005-03-04 21:09:15
|
On Fri, 4 Mar 2005, Olly Betts wrote: > This is your problem then. For floating point values, valgrind issues > an error when reading an uninitialised value from memory (for integer > values, the error isn't issued until the uninitialised value can affect > control flow or is passed to a system call, because the assembler code > compilers generate often copies around uninitialised integer values - > for example when copying a structure including uninitialised padding > bytes). > > You should be able to generate a suppression for this case if you're > happy it's safe to ignore this. Nb: This inaccuracy with FP values should be removed in Valgrind releases sometime later this year (but definitely not the next release). N |