[linrad] Re: xlinrad 02.05. Problem solved(?)

[Leif Asbrink <sm5bsz.com; leif@xxxxxxxxxxxxxxxx>]

Hi Bob,

> The first one cannot know whether or not a separate thread using a 
> pointer or the variable has initialized the contents.  In the second,  
> typically the construct inside the
> 
> if  (A ==0) {
> }
> 
> braces, requires that A be initialized to zero and that some action 
> required by the inside of braces area has been accomplished.  Otherwise, 
> there would be no need for the if test.  This is typically why the 
> second fails and the first does not. If A is an unsigned integer 
> quantity, it does not matter that B is unitialized.
Oooh! To valgrind it does - at least if A is a signed integer.
As far as I know all possible combinations of bits in a 32
bit word are legal signed integers. Is this no longer true?


Here is a real example(line numbers added manually):

int i;
int *keyboard_buffer;
128:keyboard_buffer=malloc(KEYBOARD_BUFFER_SIZE*sizeof(int));
129:i=keyboard_buffer[0];
130:fprintf(dmp,"\nTEST CASE 1: [%d]",i);
131:i>>=8;
132:i>>=8;
133:i>>=8;
134:i>>=8;
135:fprintf(dmp,"\nTEST CASE 2: [%d]",i);
136:i=0;
137:fprintf(dmp,"\nTEST CASE 3: [%d]",i);

The valgrind output is like this:
==8637== Conditional jump or move depends on uninitialised value(s)
==8637==    at 0x416ED80: vfprintf (in /lib/tls/libc-2.3.6.so)
==8637==    by 0x4176D41: fprintf (in /lib/tls/libc-2.3.6.so)
==8637==    by 0x804964C: main (xmain.c:130)
==8637==
==8637== Use of uninitialised value of size 4
==8637==    at 0x416CDB9: (within /lib/tls/libc-2.3.6.so)
==8637==    by 0x416F6BC: vfprintf (in /lib/tls/libc-2.3.6.so)
==8637==    by 0x4176D41: fprintf (in /lib/tls/libc-2.3.6.so)
==8637==    by 0x804964C: main (xmain.c:130)
==8637==
==8637== Conditional jump or move depends on uninitialised value(s)
==8637==    at 0x416CDC1: (within /lib/tls/libc-2.3.6.so)
==8637==    by 0x416F6BC: vfprintf (in /lib/tls/libc-2.3.6.so)
==8637==    by 0x4176D41: fprintf (in /lib/tls/libc-2.3.6.so)
==8637==    by 0x804964C: main (xmain.c:130)
==8637==
==8637== Conditional jump or move depends on uninitialised value(s)
==8637==    at 0x416F445: vfprintf (in /lib/tls/libc-2.3.6.so)
==8637==    by 0x4176D41: fprintf (in /lib/tls/libc-2.3.6.so)
==8637==    by 0x804964C: main (xmain.c:130)
==8637==
==8637== Conditional jump or move depends on uninitialised value(s)
==8637==    at 0x4170FDD: vfprintf (in /lib/tls/libc-2.3.6.so)
==8637==    by 0x4176D41: fprintf (in /lib/tls/libc-2.3.6.so)
==8637==    by 0x804964C: main (xmain.c:130)
==8637==
==8637== Conditional jump or move depends on uninitialised value(s)
==8637==    at 0x416F7CE: vfprintf (in /lib/tls/libc-2.3.6.so)
==8637==    by 0x4176D41: fprintf (in /lib/tls/libc-2.3.6.so)
==8637==    by 0x804964C: main (xmain.c:130)
==8637==
==8637== Conditional jump or move depends on uninitialised value(s)
==8637==    at 0x416ED80: vfprintf (in /lib/tls/libc-2.3.6.so)
==8637==    by 0x4176D41: fprintf (in /lib/tls/libc-2.3.6.so)
==8637==    by 0x8049668: main (xmain.c:135)
==8637==
==8637== Use of uninitialised value of size 4
==8637==    at 0x416CDB9: (within /lib/tls/libc-2.3.6.so)
==8637==    by 0x416F6BC: vfprintf (in /lib/tls/libc-2.3.6.so)
==8637==    by 0x4176D41: fprintf (in /lib/tls/libc-2.3.6.so)
==8637==    by 0x8049668: main (xmain.c:135)
==8637==
==8637== Conditional jump or move depends on uninitialised value(s)
==8637==    at 0x416CDC1: (within /lib/tls/libc-2.3.6.so)
==8637==    by 0x416F6BC: vfprintf (in /lib/tls/libc-2.3.6.so)
==8637==    by 0x4176D41: fprintf (in /lib/tls/libc-2.3.6.so)
==8637==    by 0x8049668: main (xmain.c:135)
==8637==
==8637== Conditional jump or move depends on uninitialised value(s)
==8637==    at 0x416F445: vfprintf (in /lib/tls/libc-2.3.6.so)
==8637==    by 0x4176D41: fprintf (in /lib/tls/libc-2.3.6.so)
==8637==    by 0x8049668: main (xmain.c:135)
==8637==
==8637== Conditional jump or move depends on uninitialised value(s)
==8637==    at 0x4170FDD: vfprintf (in /lib/tls/libc-2.3.6.so)
==8637==    by 0x4176D41: fprintf (in /lib/tls/libc-2.3.6.so)
==8637==    by 0x8049668: main (xmain.c:135)
==8637==
==8637== Conditional jump or move depends on uninitialised value(s)
==8637==    at 0x416F7CE: vfprintf (in /lib/tls/libc-2.3.6.so)
==8637==    by 0x4176D41: fprintf (in /lib/tls/libc-2.3.6.so)
==8637==    by 0x8049668: main (xmain.c:135)
==8637==

while the file (dmp) contains the following:

TEST CASE 1: [0]
TEST CASE 2: [0]
TEST CASE 3: [0]

It is obvious that valgrind tracks the history of 
the contents of i. The value has to be 0 after
32 right shifts and indeed the printed value is 
zero all the time. There must be some mechanism
that valgrind uses to know that the 0-value is
"just by accident". I would like to see an earlier
output from it.

> gdb and valgrind are tools that aid (as you can see) but they cannot 
> tease apart all of the logical ways things can happen.  If I may,  they 
> are not mind readers,  they are the assistant in the audience aiding the 
> mentalist by picking the unsuspecting customer's pocket for 
> information!  With that attitude,  you will find a way to properly use 
> valgrind or gdb to eventually come to arrive at the error by logical 
> inference and deduction.  I wish I could give a more satisfying answer 
> but you can see why it is not possible for valgrind or gdb to understand 
> all of the ways these things can happen.
I hope I explained my problem better now. Valgrind knows something
about the history behind the value in a specific memory location.
Valgrind issues errors on comparisons between fully legal values
because it knows the result of the comparison is undetermined.
For Linrad the result does not matter in such cases (normally)
but most probably there are bugs where it does matter - that is why
it would be a good idea to get rid of all these "errors". If the
valgrind output would tell me (in the above example) that the 
undetermined value of i is traced from line 129 life would be
much easier.....
 
> The best case you can hope for is an explosion where valgrind gives you 
> the line of interest and you back it up logically to the nexus of the 
> problem.
If this is really true I will leave the errors in place for the 
time being:-(

73

Leif  /  SM5BSZ






#############################################################
This message is sent to you because you are subscribed to
  the mailing list <linrad@xxxxxxxxxxxxxxxxxxxxx>.
To unsubscribe, E-mail to: <linrad-off@xxxxxxxxxxxxxxxxxxxxx>
To switch to the DIGEST mode, E-mail to <linrad-digest@xxxxxxxxxxxxxxxxxxxxx>
To switch to the INDEX mode, E-mail to <linrad-index@xxxxxxxxxxxxxxxxxxxxx>
Send administrative queries to  <linrad-request@xxxxxxxxxxxxxxxxxxxxx>


LINRADDARNIL