Gsoap / valgrind; NO leaks except memory errors

Question

I am writing a web service client with gSoap and am using Valgrind to check for memory problems.

Valgrind reports NO LEAKS, but shows this strange (at least for me) memory error message:

==3529== Conditional jump or move depends on uninitialised value(s) ==3529== at 0x405D6DC: soap_reference (stdsoap2.c:6926) ==3529== by 0x405305D: soap_serialize_string (sepomexC.c:4982) ==3529== by 0x404AF5E: soap_serialize_ns1__asentamientosPorCodigoPostalRqType (sepomexC.c:2629) ==3529== by 0x40500F3: soap_serialize_PointerTons1__asentamientosPorCodigoPostalRqType (sepomexC.c:4103) ==3529== by 0x4046666: soap_serialize___sep__consultarAsentamientosPorCodigoPostal (sepomexC.c:1233) ==3529== by 0x4053A7D: soap_call___sep__consultarAsentamientosPorCodigoPostal (sepomexClient.c:186) ==3529== by 0x40417CA: consultarAsentamientosPorCodigoPostal (main.c:73) ==3529== by 0x804870C: main (sepomexmain.c:31) ==3529== ==3529== Conditional jump or move depends on uninitialised value(s) ==3529== at 0x4061AA5: soap_element_id (stdsoap2.c:9583) ==3529== by 0x4068B0C: soap_outstring (stdsoap2.c:12681) ==3529== by 0x4052DAE: soap_out_xsd__integer (sepomexC.c:4918) ==3529== by 0x404B062: soap_out_ns1__asentamientosPorCodigoPostalRqType (sepomexC.c:2643) ==3529== by 0x4050179: soap_out_PointerTons1__asentamientosPorCodigoPostalRqType (sepomexC.c:4111) ==3529== by 0x4046698: soap_out___sep__consultarAsentamientosPorCodigoPostal (sepomexC.c:1238) ==3529== by 0x4046818: soap_put___sep__consultarAsentamientosPorCodigoPostal (sepomexC.c:1274) ==3529== by 0x4053AF6: soap_call___sep__consultarAsentamientosPorCodigoPostal (sepomexClient.c:193) ==3529== by 0x40417CA: consultarAsentamientosPorCodigoPostal (main.c:73) ==3529== by 0x804870C: main (sepomexmain.c:31) ==3529== ==3529== HEAP SUMMARY: ==3529== in use at exit: 0 bytes in 0 blocks ==3529== total heap usage: 160 allocs, 160 frees, 16,161 bytes allocated ==3529== ==3529== All heap blocks were freed -- no leaks are possible ==3529== ==3529== For counts of detected and suppressed errors, rerun with: -v ==3529== Use --track-origins=yes to see where uninitialised values come from ==3529== ERROR SUMMARY: 3 errors from 2 contexts (suppressed: 21 from 8) 

NO LEAKS is good news, but are these errors important? As far as I understand, they are generated in stdsoap2.c (gSoap file).

Thanks.

EDIT: Thanks for your answers. As some of you told me that I have uninitialized stuff, it was my struct request variable. I fixed it as follows:

 struct ns1__myRequestType request; memset(&request, 0, sizeof(struct ns1__myRequestType)); 

Now Valgrind's output is "clean" :) Thanks a lot.

Answer 1

This mainly refers to the fact that some branches are taken based on uninitialized variables. They can simply be automatic variables, local in scope, of a library function that are allocated on the stack, and no values ​​were assigned before they were used in if , while , switch expressions, or some other form of branch expression. Generally speaking, this is not very good, since it can lead to undefined behavior, but if the error is internal to the library, the authors can perform some operation of superimposing the alleged memory, etc. With variables, which makes them unofficially “initialized”, rather than explicitly initialized with the standard C syntax. Another possibility is that you could also pass pointers to uninitialized variables to one of the library functions, which would be a bad form of programming and possibly created unpredictable results or security risks.