gsoap/valgrind; NO leaks but memory errors

Question

I'm writting a web service client with gSoap and using Valgrind to check for memory issues.

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

==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)

The NO LEAKS are good news but, are this errors important? As I understand they are generated in stdsoap2.c (a gSoap file).

Thanks.

EDIT: Thanks for your answers. As some of you told me I had uninitialized stuff, it was my request struct variable. I fixed it this way:

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

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

Quadripartite

Can you post the code of your main()? – Galligan

Yes they are usually very important, and it might be because your code passed uninitialized stuff into the gSoap library. – Eared

Answer 1

It basically refers to the fact there are some branches being taken based on variables that are uninitialized. They could simply be automatic variables local in scope to the library function that are allocated on the stack and were not assigned values before they were used in a if, while, switch, or other form of branching expression. Generally speaking this isn't a good thing to-do as it could result in undefined behavior, but if the error is internal to the library, the writers could be doing some type of assumed memory overlay operation, etc. with the variables that makes them informally "initialized" rather than explicitly initialized in standard C syntax. Another possibility is you could have also passed pointers to uninitialized variables to one of the library functions, which would be poor programming form and possibly create unpredictable results or security risks.

Normalize