fix memory leaks #256
Closed
fix memory leaks #256
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…erse-engineering/develop Next Version
…erse-engineering/develop Next Version (hotfix)
Fixes error descriped here: toniebox-reverse-engineering#237
…ch-1 Allow compilation on FreeBSD and maybe other UNIX systems
…erse-engineering/revert-238-patch-1 Revert "Allow compilation on FreeBSD and maybe other UNIX systems"
|
There were 2 more leaks which were caught with clang-tidy: clang-analyzer-unix.Malloc |
|
Please target the develop branch, as the master contains the current stable version. |
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There were 3 memory leaks, which were caught by the tool: infer
1 was an exit path before the free.
The other is a rather ugly construct, but is necessary so the variable named string can be freed.
It must be mentioned though, that some more tweaking should be done, as osAllocMem could actually fail (unlikely, but not unheard). Return values of allocations are nowhere really handled, so this PR just addresses the obvious memory leaking.