gsoap/valgrind; NO perdite ma errori di memoria

Question

Sto scrivendo un client di servizio web con gSoap e usando Valgrind per verificare problemi di memoria.

Valgrind riporta PERDITE ma mostra questo strano (almeno per me) messaggi di errore di memoria:

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

Il PERDITE sono una buona notizia, ma, sono questi errori importanti? Come ho capito sono generati in stdsoap2.c (un file gSoap).

Grazie.

EDIT: Grazie per le vostre risposte. Come alcuni di voi mi hanno detto che avevo roba non inizializzata, era la mia variabile struct di richiesta. L'ho risolto in questo modo:

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

Ora l'uscita di Valgrind è "pulita" :) grazie mille.

Answer 1

Fondamentalmente si riferisce al fatto che alcuni rami vengono presi in base a variabili non inizializzate. Potrebbero essere semplicemente variabili automatiche locali nell'ambito della funzione di libreria allocate nello stack e ai valori non assegnati prima che fossero utilizzate in un if, while, switch o altra forma di espressione di diramazione. In generale, non è una cosa buona da fare in quanto potrebbe comportare un comportamento indefinito, ma se l'errore è interno alla libreria, gli scrittori potrebbero eseguire un tipo di operazione di sovrapposizione della memoria presunta, ecc. Con le variabili che rendono informalmente "inizializzati" anziché inizializzati esplicitamente nella sintassi C standard. Un'altra possibilità è che potresti aver passato anche dei puntatori a variabili non inizializzate a una delle funzioni della libreria, il che sarebbe una cattiva forma di programmazione e probabilmente creare risultati imprevedibili o rischi per la sicurezza.