|
From: Mila R. <mi...@ru...> - 2006-12-22 23:00:30
|
Hello,
I am currently working on a project to port some C-code from SGI to other
platforms. The program now runs on Linux and produces the same results as
on SGI. I would like to use valgrind to see if there are any undetected
memory leaks. There are plenty but since I cannot find the source I would
like to as for hints how to proceed and spot the errors.
The code (with lines) causing the error message:
--------------------------------------------------------------------------
1403 printf("-------DEBUG: %d, %d----\n", *atomCount, *maxAtomCount);
1404 printf("-------DEBUG: %p, %p----\n", atomCount, maxAtomCount);
1405 if (*atomCount < *maxAtomCount)
1406 {
1407 atomPtr = *atomList + *atomCount;
1408 (*atomCount)++;
1409
1410 return( atomPtr );
1411 }
--------------------------------------------------------------------------
The program is run with
valgrind -v <progname> <prog-options> > valgrind.log 2>&1
An extract from valgrind.log reads:
-------DEBUG: 7, 32----
-------DEBUG: 0x41d6b7c, 0x41d6b80----
-------DEBUG: 8, 32----
-------DEBUG: 0x41d6b7c, 0x41d6b80----
-------DEB==7810== Use of uninitialised value of size 4
==7810== at 0x40B74B9: (within /lib/tls/i686/cmov/libc-2.3.6.so)
==7810== by 0x40BB5EC: vfprintf (in /lib/tls/i686/cmov/libc-2.3.6.so)
==7810== by 0x40C11A2: printf (in /lib/tls/i686/cmov/libc-2.3.6.so)
==7810== by 0x8143AA1: getNextAtomPtr (pdb.c:1403)
==7810== by 0x8144632: setSegAtomInfo (pdb.c:1887)
==7810== by 0x81432C3: indexPDB (pdb.c:1050)
==7810== by 0x8142F28: readPDB (pdb.c:908)
==7810== by 0x805B48D: main (pales.c:705)
==7810==
==7810== Conditional jump or move depends on uninitialised value(s)
==7810== at 0x40B74C1: (within /lib/tls/i686/cmov/libc-2.3.6.so)
==7810== by 0x40BB5EC: vfprintf (in /lib/tls/i686/cmov/libc-2.3.6.so)
==7810== by 0x40C11A2: printf (in /lib/tls/i686/cmov/libc-2.3.6.so)
==7810== by 0x8143AA1: getNextAtomPtr (pdb.c:1403)
==7810== by 0x8144632: setSegAtomInfo (pdb.c:1887)
==7810== by 0x81432C3: indexPDB (pdb.c:1050)
==7810== by 0x8142F28: readPDB (pdb.c:908)
==7810== by 0x805B48D: main (pales.c:705)
... 12 more reports on "
UG: 9, 32----
-------DEBUG: 0x41d6b7c, 0x41d6b80----
-------DEBUG: 10, 32----
-------DEBUG: 0x41d6b7c, 0x41d6b80----
-------DEBUG: 11, 32----
-------DEBUG: 0x41d6b7c, 0x41d6b80----
My questions:
Do the messages from valgrind refer to when the variable *atomCount has
the value 9, or can it refer to a later stage of that loop?
If it does refer to when *atomCount==9, how can one of the two variables
be uninitialised? Since they are very regular (*atomCount properly
counting up), doesn't that indicate that it is properly initialised?
I have been searching the code to figure out at what stage one of the two
pointers used in line 1405 might be uninitialised, but without success.
Are there other tips that might help me find out what causes valgrind to
issue this message, i.e., trace back where the uninitialised variable stem
from?
valgring version
valgrind-3.2.1-Debian (i686),
code compiled with
gcc version 4.1.2 20061028 (prerelease) (Debian 4.1.1-19)
and options
-O0 -g -Wall
I hope I provided all necessary information and would be very grateful for
any hints as to how to proceed.
Mila.
|
|
From: Julian S. <js...@ac...> - 2006-12-25 09:05:07
|
One idea is to change your two printfs into four printfs, so that it is easier to see which of atomCount/*atomCount/maxAtomCount/*maxAtomCount is the problem. Also I suggest putting fflush(stdout);fflush(stderr); after each printf. What you ask is the "standard problem" with memcheck - it is good at finding uninitialised values but it is often difficult to find the cause of the problem. There is some work in progress which might improve this. In the meantime the best we can offer is to try "client requests"; see http://valgrind.org/docs/manual/mc-manual.html#mc-manual.clientreqs and in particular VALGRIND_CHECK_MEM_IS_ADDRESSABLE and VALGRIND_CHECK_MEM_IS_DEFINED. Are you sure atomCount and maxAtomCount always point to sensible locations? J > -------------------------------------------------------------------------- > 1403 printf("-------DEBUG: %d, %d----\n", *atomCount, *maxAtomCount); > 1404 printf("-------DEBUG: %p, %p----\n", atomCount, maxAtomCount); > 1405 if (*atomCount < *maxAtomCount) > 1406 { > 1407 atomPtr = *atomList + *atomCount; > 1408 (*atomCount)++; > 1409 > 1410 return( atomPtr ); > 1411 } > -------------------------------------------------------------------------- > The program is run with > valgrind -v <progname> <prog-options> > valgrind.log 2>&1 > An extract from valgrind.log reads: > -------DEBUG: 7, 32---- > -------DEBUG: 0x41d6b7c, 0x41d6b80---- > -------DEBUG: 8, 32---- > -------DEBUG: 0x41d6b7c, 0x41d6b80---- > -------DEB==7810== Use of uninitialised value of size 4 > ==7810== at 0x40B74B9: (within /lib/tls/i686/cmov/libc-2.3.6.so) > ==7810== by 0x40BB5EC: vfprintf (in /lib/tls/i686/cmov/libc-2.3.6.so) > ==7810== by 0x40C11A2: printf (in /lib/tls/i686/cmov/libc-2.3.6.so) > ==7810== by 0x8143AA1: getNextAtomPtr (pdb.c:1403) > ==7810== by 0x8144632: setSegAtomInfo (pdb.c:1887) > ==7810== by 0x81432C3: indexPDB (pdb.c:1050) > ==7810== by 0x8142F28: readPDB (pdb.c:908) > ==7810== by 0x805B48D: main (pales.c:705) > ==7810== > ==7810== Conditional jump or move depends on uninitialised value(s) > ==7810== at 0x40B74C1: (within /lib/tls/i686/cmov/libc-2.3.6.so) > ==7810== by 0x40BB5EC: vfprintf (in /lib/tls/i686/cmov/libc-2.3.6.so) > ==7810== by 0x40C11A2: printf (in /lib/tls/i686/cmov/libc-2.3.6.so) > ==7810== by 0x8143AA1: getNextAtomPtr (pdb.c:1403) > ==7810== by 0x8144632: setSegAtomInfo (pdb.c:1887) > ==7810== by 0x81432C3: indexPDB (pdb.c:1050) > ==7810== by 0x8142F28: readPDB (pdb.c:908) > ==7810== by 0x805B48D: main (pales.c:705) > ... 12 more reports on " > UG: 9, 32---- > -------DEBUG: 0x41d6b7c, 0x41d6b80---- > -------DEBUG: 10, 32---- > -------DEBUG: 0x41d6b7c, 0x41d6b80---- > -------DEBUG: 11, 32---- > -------DEBUG: 0x41d6b7c, 0x41d6b80---- > > > My questions: > Do the messages from valgrind refer to when the variable *atomCount has > the value 9, or can it refer to a later stage of that loop? > > If it does refer to when *atomCount==9, how can one of the two variables > be uninitialised? Since they are very regular (*atomCount properly > counting up), doesn't that indicate that it is properly initialised? > > I have been searching the code to figure out at what stage one of the two > pointers used in line 1405 might be uninitialised, but without success. > Are there other tips that might help me find out what causes valgrind to > issue this message, i.e., trace back where the uninitialised variable stem > from? > > valgring version > valgrind-3.2.1-Debian (i686), > code compiled with > gcc version 4.1.2 20061028 (prerelease) (Debian 4.1.1-19) > and options > -O0 -g -Wall > > I hope I provided all necessary information and would be very grateful for > any hints as to how to proceed. > > Mila. > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |