Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Remove map_free macros#4166

Merged
ethomson merged 2 commits intolibgit2:masterlibgit2/libgit2:masterfrom
pks-t:pks/map-free-fixpks-t/libgit2:pks/map-free-fixCopy head branch name to clipboard
Mar 20, 2017
Merged

Remove map_free macros#4166
ethomson merged 2 commits intolibgit2:masterlibgit2/libgit2:masterfrom
pks-t:pks/map-free-fixpks-t/libgit2:pks/map-free-fixCopy head branch name to clipboard

Conversation

@pks-t
Copy link
Member

@pks-t pks-t commented Mar 20, 2017

I just noticed a subtle bug via Coverity which I introduced in my recent refactoring of the map interfaces. The git_map_free functions were implemented as macros, but in fact in a subtly wrong way where the statements were not grouped together by a do { ... } while (0) block. I think no real issues were introduced by this, but I took it as a hint to remove the macro altogether. One caller needed to be fixed, but this was a double-free anyway and as such wrong.

pks-t added 2 commits March 20, 2017 08:59
We currently call `git_strmap_free` on `checkout_data.mkdir_map` in the
`checkout_data_clear` function. The only thing protecting us from a
double-free is that the `git_strmap_free` function is in fact not a
function, but a macro that also sets the map to NULL.

Remove the second call to `git_strmap_free` and explicitly set the map
member to NULL.
The `map_free` functions were not implemented as functions but instead
as macros which also set the map to NULL. While this is most certainly
sensible in most cases, we should prefer the more obvious behavior,
namingly leaving the map pointer intact.

Furthermore, this macro has been refactored incorrectly during the
map-refactorings: the two statements are not actually grouped together
by a `do { ... } while (0)` block, as it is required for macros to
match the behavior of functions more closely. This has led to at least
one subtle nesting error in `pack-objects.c`. The following code block

```
    if (pb->object_ix)
        git_oidmap_free(pb->object_ix);
```

would be expanded to

```
    if (pb->object_ix)
        git_oidmap__free(pb->object_ix); pb->object_ix = NULL;
```

which is not what one woudl expect. While it is not a bug here as it
would simply become a no-op, the wrong implementation could lead to bugs
in other occasions.

Fix this by simply removing the macro altogether and replacing it with
real function calls. This leaves the burden of setting the pointer to
NULL afterwards to the caller, but this is actually expected and behaves
like other `free` functions.
@ethomson
Copy link
Member

👍

@ethomson ethomson merged commit 1d50f95 into libgit2:master Mar 20, 2017
@pks-t pks-t deleted the pks/map-free-fix branch March 28, 2017 06:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

Morty Proxy This is a proxified and sanitized view of the page, visit original site.