On 24-10-24 14:33, Daniel Feenberg via Valgrind-users wrote:
I am a bit inexperienced with Valgrind which reports an uninitialized
variable in my 34,000 line program. But the message comes from a branch
deep in libgfortran. After some experimentation, I created the following
example program which demonstrates my difficulty:
cat -n test.for
1 program test
2 integer i,j
3 j=i+1
4 write(*,*) j
5 stop
6 end
I compile and run with:
gfortran -g stuff.for
valgrind --track-origins=yes ./a.out
and get a great deal of output pointing to line 4. But the first use of
the uninitialized value is in line 3. In this case the error is obvious,
but IRL I haven't been able to identify the source. I thought "track-
origins" would do that. Is there an option or other way to ask Valgrind
to be a little stricter, and flag the use of an unidentified variable in
an assignment, not just in a condition?
--track-origins=yes tells memcheck to record the origins of
uninitilalized memory.
It has done that and added
==4095841== Uninitialised value was created by a stack allocation
==4095841== at 0x401176: MAIN__ (test.for:1)
With all errors Valgrind will also read debuginfo if available to give
you the source and line and when possible the name of the variable. In
this case it hasn't determined the name of the variable - I don't know why.
Uninitialized read errors are not triggered simply by reading
uninitialized memory. There are many cases where uninitialized memory
gets copied in a harmless manner. That would be overwhelming. Instead we
only trigger errors when the uninitialized memory affects the observable
behaviour of the test exe. Hence "Conditional jump or move depends on
uninitialised value(s)". So you have to do some digging to search for
the place in the code where the variable should have been initialized.
A+
Paul
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
