Skip to content

Fixed all memory leaks and almost all undefined behaviour #4025

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 7 commits into from
Apr 21, 2024
Merged

Fixed all memory leaks and almost all undefined behaviour #4025

merged 7 commits into from
Apr 21, 2024

Conversation

alexlnkp
Copy link
Contributor

@alexlnkp alexlnkp commented Apr 12, 2024

Misc

  • Initialized as many variables as possible to avoid any undefined behaviour.
  • Removed fclose(f) line at tests/paramgrill.c in createBuffers function, since if f couldn't initialize properly, there's no need to close it either.
  • Added a fallback at tests/regression/result.c in result_get_error_string(result_t result) function, just in case.

MemLeaks

Fixed memory leaks/possible memory leaks at:

  • doc/educational_decoder/harness.c during read_file function.
  • tests/bigdict.c now goes to cleanup if condition (!buffer || !out || !roundtrip || !cctx || !dctx) is met, instead of simply returning 1.
  • zlibWrapper/gzwrite.c now frees state.state before returning from the function.

(void)argc;
(void)argv;

if (!buffer || !out || !roundtrip || !cctx || !dctx) {
fprintf(stderr, "Allocation failure\n");
return 1;
_exit_code = 1;
goto cleanup;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@@ -1273,7 +1273,6 @@ static int createBuffers(buffers_t* buff, const char* const * const fileNamesTab
f = fopen(fileNamesTable[n], "rb");
if (f==NULL) {
DISPLAY("impossible to open file %s\n", fileNamesTable[n]);
fclose(f);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@Cyan4973 Cyan4973 self-assigned this Apr 12, 2024
@Cyan4973
Copy link
Contributor

Cyan4973 commented Apr 12, 2024

The first list of changes, detailed in the summary and present in the first commit, looks mostly good to me (with the exception of gzwrite change, which is likely wrong).

But then, there is a second list of changes, named "fixed ISO C incompatibility" in commits 2 and 3, which are a bit more concerning and would deserve some scrutiny. And strangely, while they appear in the commit timeline, I don't see them in the GitHub PR comparison view.
It's the first time I observe such discrepancy, and it means that, I'm not even sure what's the exact content of this PR...

@@ -64,6 +64,8 @@ local int gz_init(gz_statep state) {
strm->next_out = state.state->out;
state.state->x.next = strm->next_out;
}

free(state.state);
Copy link
Contributor

@Cyan4973 Cyan4973 Apr 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That one is weird.
I'm not even sure what's going on in this code.

One of the first actions in this function is : state.state->in = (unsigned char*)malloc(state.state->want << 1);,
which presumes that state.state is already allocated (should probably be asserted), before entering the function,
which means that, something else has allocated state.state, and therefore something else is in charge of freeing it.
I don't see how it could be good to free it here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apologies, You're right. That was an oversight from me.
I'll fix this tomorrow morning... Again, sorry for the inconvenience

@alexlnkp
Copy link
Contributor Author

The first list of changes, detailed in the summary and present in the first commit, looks mostly good to me (with the exception of gzwrite change, which is likely wrong).

But then, there is a second list of changes, named "fixed ISO C incompatibility" in commits 2 and 3, which are a bit more concerning and would deserve some scrutiny. And strangely, while they appear in the commit timeline, I don't see them in the GitHub PR comparison view. It's the first time I observe such discrepancy, and it means that, I'm not even sure what's the exact content of this PR...

Yeah, about those,
Basically, i decided to initialize structs by = {}, while i completely forgot that this is not allowed on C version that one of the checks runs on

@alexlnkp alexlnkp requested a review from Cyan4973 April 13, 2024 10:25
@@ -50,6 +50,7 @@ static buffer_s read_file(const char *path)

fclose(f);
buffer_s const b = { ptr, size };
free(ptr);
Copy link
Contributor

@Cyan4973 Cyan4973 Apr 14, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change is incorrect :
the whole point of this function is to return a populated buffer, passed as a member of the buffer_s structure, effectively transferring ownership to the caller of the function (which will have to free it later, using the provided freeBuffer() function).

Maybe this could be documented if it's not clear enough...

@@ -234,7 +234,7 @@ int gzwrite _Z_OF((gzFile, const void *, unsigned));

int gzwrite(gzFile gz, const void *buf, unsigned len) {
z_stream *strm;
unsigned char out[BUFLEN];
unsigned char out[BUFLEN] = 0;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you meant { 0 } ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

God damn, I'm absent-minded...
Sorry I made so much mistakes in something that's supposed to fix stuff...

Will fix this though, thanks for noticing

fixed where i made it to init with just the first one being set to 0
@alexlnkp alexlnkp requested a review from Cyan4973 April 14, 2024 10:56
Copy link
Contributor

@Cyan4973 Cyan4973 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@Cyan4973 Cyan4973 merged commit eb54140 into facebook:dev Apr 21, 2024
@Cyan4973
Copy link
Contributor

Cyan4973 commented Oct 1, 2024

There is another bug in this PR,
in result.c, line 28:

return "unknown error - " + result_get_error(result);

This formulation is erroneous:
it's not python, it will not concatenate 2 strings to create a new one.
Instead, it results in adding some integer to a pointer,
producing another pointer somewhere in memory, potentially out of bound.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants