gsoap/valgrind; KEINE Lecks, aber Speicherfehler

Question

Ich schreibe einen Web-Service-Client mit gSoap und Valgrind verwenden, um nach Speicherproblemen zu suchen.

Valgrind berichtet LECKAGEN NO zeigt aber diese seltsame (zumindest für mich) Speicherfehlermeldungen:

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

Die keine undichten Stellen sind gute Nachrichten, aber sind diese Fehler wichtig? Wie ich es verstehe, werden sie in stdsoap2.c (eine gSoap-Datei) generiert.

Danke.

EDIT: Vielen Dank für Ihre Antworten. Da einige von Ihnen mir sagten, ich hätte nicht initialisiertes Zeug, war es meine Anfrage Strukturvariable. Ich reparierte es so:

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

Jetzt ist Valgrinds Ausgabe "sauber" :) vielen Dank.

Answer 1

Es bezieht sich im Wesentlichen auf die Tatsache, dass einige Zweige basierend auf Variablen, die nicht initialisiert sind, genommen werden. Sie könnten einfach automatische Variablen sein, die lokal im Umfang der Bibliotheksfunktion sind, die auf dem Stapel zugeordnet sind, und ihnen wurden keine Werte zugewiesen, bevor sie in einem if, while, switch oder einer anderen Form eines Verzweigungsausdrucks verwendet wurden. Im Allgemeinen ist dies keine gute Sache zu tun, da dies zu einem undefinierten Verhalten führen kann. Wenn der Fehler jedoch in der Bibliothek auftritt, könnten die Schreiber eine Art von angenommener Speicherüberlagerungsoperation usw. mit den Variablen, die dies vornimmt, ausführen Sie werden informell "initialisiert" und nicht explizit in der Standard-C-Syntax initialisiert. Eine andere Möglichkeit wäre, dass Sie auch Zeiger auf nicht initialisierte Variablen an eine der Bibliotheksfunktionen übergeben könnten, was eine schlechte Programmierform wäre und möglicherweise unvorhersehbare Ergebnisse oder Sicherheitsrisiken erzeugen würde.