uz.exe hangs instead of exiting about orangec

[LADSoft]

Hi Alexey!

Thanks for your elaborate feedback. I will look at UZ.C to fix the
'double free' and to see if I can clean up some of the warnings. I
agree UZ.C isn't a happy piece of code, some of the mess is from
contributors sigh although I probably should have payed more attention
to it when that was done.

The rest of the repository is a little cleaner... I spent november and
part of december compiling the tool chain with four or five different
compilers including CLANG and cleaned up a lot of issues as you suggest
as possible :) A lot of it was fluff, but the compilations did
highlight some outright bugs as well. I didn't think to screen UZ.C
however...

David

Alexey Frunze wrote:

Cause: duplicated fclose(FFzipfile) in unzip().

Problem exists in 3 different files named uz.c.

Repro: compile uz.c for Windows with Smaller C then try to unzip a
small text file on Windows 7 x64. Sometimes it uz.exe would exit, but
sometimes it would hang after unzipping.

What happens under the hood:
exit(), which runs after main(), calls fclose(stdout), which calls
free() to free stdout's buffer and ultimately kernel32::HeapFree()
hangs because of the memory corruption previously caused by a
double-free bug with 2 calls to fclose(FFzipfile).

Side note: uz.c is horrible. It compiles with lots of warnings with gcc.

One of the things you may find in the warnings is this nice line of code:

| for (i ==0 ; i < len; i++)
|

Note == instead of =.

I haven't tried anything else from the repository, but I think it
might be a good idea to clean up the code a little bit everywhere and
maybe try compiling it using different compilers to catch bad stuff.

—
Reply to this email directly or view it on GitHub
#4.

[alexfru]

I haven't reviewed all the changes, but src/uz/uz.c isn't hanging anymore. I guess, you could close the issue.

[LADSoft]

yeah i ran it through clang and restructured some code, should be a little better. Thanks again!