Libzip example contains uninitialized values ​​when validating with Valgrind

Question

I use libzip to process zip files and base my code on the example found in Rodrigo on this question . Here is his code for quick reference:

#include <zip.h> int main() { //Open the ZIP archive int err = 0; zip *z = zip_open("foo.zip", 0, &err); //Search for the file of given name const char *name = "file.txt"; struct zip_stat st; zip_stat_init(&st); zip_stat(z, name, 0, &st); //Alloc memory for its uncompressed contents char *contents = new char[st.size]; //Read the compressed file zip_file *f = zip_fopen(z, "file.txt", 0); zip_fread(f, contents, st.size); zip_fclose(f); //And close the archive zip_close(z); } 

I traced the errors that I subsequently received from Valgrind back to this code - it complains about the uninitialized value when opening the zipped file.txt file using 'zip_fopen () `.

 ==29256== Conditional jump or move depends on uninitialised value(s) ==29256== at 0x5B4B290: inflateReset2 (in /usr/lib/libz.so.1.2.3.4) ==29256== by 0x5B4B37F: inflateInit2_ (in /usr/lib/libz.so.1.2.3.4) ==29256== by 0x4E2EB8C: zip_fopen_index (in /usr/lib/libzip.so.1.0.0) ==29256== by 0x400C32: main (main.cpp:24) ==29256== Uninitialised value was created by a heap allocation ==29256== at 0x4C244E8: malloc (vg_replace_malloc.c:236) ==29256== by 0x5B4B35B: inflateInit2_ (in /usr/lib/libz.so.1.2.3.4) ==29256== by 0x4E2EB8C: zip_fopen_index (in /usr/lib/libzip.so.1.0.0) ==29256== by 0x400C32: main (main.cpp:24) ==29256== ==29256== ==29256== HEAP SUMMARY: ==29256== in use at exit: 71 bytes in 1 blocks ==29256== total heap usage: 26 allocs, 25 frees, 85,851 bytes allocated ==29256== ==29256== 71 bytes in 1 blocks are definitely lost in loss record 1 of 1 ==29256== at 0x4C24A72: operator new[](unsigned long) (vg_replace_malloc.c:305) ==29256== by 0x400BEE: main (main.cpp:19) 

I do not see where the uninitialized value comes from in this code. Can anyone trace this, or is the error related to libzip itself? Should I switch to another zip library like Minizip?

EDIT: 71 bytes is the contents of file.txt that was read in the delete[] contents; tag delete[] contents; marked at the end will eliminate this.

(I would leave a comment on the original answer to draw attention to the problem, but I do not have the required representative.)

Answer 1

You made me look :)

Yes, this is an error inside zlib (used by libzip), since both allocation and memory usage are inside inflateInit2_ with the same call. Your code does not even have the ability to access this memory.

I can repeat the problem using zlib 1.2.3, but it no longer appears in 1.2.7. I did not have code for version 1.2.3, but if you look at it, I would check the state initialization and how it was used inside inflateReset2 .

Edit: Tracking the problem, I downloaded the Ubuntu source package for zlib (1.2.3.4) and the violation line:

 if (state->wbits != windowBits && state->window != Z_NULL) { 

wbits not initialized before and causes a warning. The strange thing is that neither the original version of zlib 1.2.3 nor 1.2.4 has this problem, it seems unique to Ubuntu. 1.2.3 does not even have the function inflateReset2, and 1.2.4 has the right:

 if (state->window != Z_NULL && state->wbits != (unsigned)windowBits) { 

since window previously initialized to Z_NULL, uninitialized reading of wbits will not occur.