2012-08-30 19 views
7

Escribo un cliente de servicio web con gSoap y uso Valgrind para verificar si hay problemas de memoria.gsoap/valgrind; SIN goteos, pero errores de memoria

Valgrind informes no haya fugas, pero muestra este extraño (al menos para mí) mensajes de error de 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) 

El no haya fugas son buenas noticias, pero, son estos errores importantes? Según tengo entendido, se generan en stdsoap2.c (un archivo gSoap).

Gracias.

EDIT: Gracias por sus respuestas. Como algunos de ustedes me dijeron que tenía material no inicializado, era mi variable de estructura de solicitud. Lo arreglé de esta manera:

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

Ahora la salida de Valgrind es "limpia" :) muchas gracias.

+0

¿Se puede publicar el código de su 'main()'? – hmjd

+2

Sí, por lo general, son muy importantes, y es posible que su código haya pasado material no inicializado a la biblioteca de gSoap. – nos

Respuesta

3

Básicamente se refiere al hecho de que se están tomando algunas ramas basadas en variables que no están inicializadas. Podrían ser simplemente variables automáticas de alcance local para la función de biblioteca que están asignadas en la pila y no se les asignaron valores antes de que se utilizaran en un if, while, switch u otra forma de expresión de bifurcación. En general, esto no es una buena tarea, ya que podría dar como resultado un comportamiento indefinido, pero si el error es interno de la biblioteca, los escritores podrían estar haciendo algún tipo de operación de superposición de memoria asumida, etc. con las variables que hace informalmente "inicializados" en lugar de inicializados explícitamente en la sintaxis C estándar. Otra posibilidad es que también podría haber pasado punteros a variables no inicializadas a una de las funciones de la biblioteca, que sería una forma de programación deficiente y posiblemente crearía resultados impredecibles o riesgos de seguridad.

Cuestiones relacionadas