Safe-guard the Windows code a bit more against getenv() problems #127
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
Running up to v2.21.0, we fixed two bugs that were made prominent by the Windows-specific change to retain copies of only the 30 latest getenv() calls' returned strings, invalidating any copies of previous getenv() calls' return values. While this really shines a light onto bugs of the form where we hold onto getenv()'s return values without copying them, it is also a real problem for users. And even if Jeff King's patches merged via 773e408 (Merge branch 'jk/save-getenv-result', 2019-01-29) provide further work on that front, we are far from done. Just one example: on Windows, we unset environment variables when spawning new processes, which potentially invalidates strings that were previously obtained via getenv(), and therefore we have to duplicate environment values that are somehow involved in spawning new processes (e.g. GIT_MAN_VIEWER in show_man_page()). We do not have a chance to investigate, let address, all of those issues in time for v2.21.0, so let's at least help Windows users by increasing the number of getenv() calls' return values that are kept valid. The number 64 was determined by looking at the average number of getenv() calls per process in the entire test suite run on Windows (which is around 40) and then adding a bit for good measure. And it is a power of two (which would have hit yesterday's theme perfectly). Signed-off-by: Johannes Schindelin <[email protected]>
|
/submit |
|
Submitted as [email protected] |
![gitgitgadget[bot]](https://avatars.githubusercontent.com/in/12836?s=60&v=4){kind=small}
|
This patch was applied directly to |
| @@ -1632,7 +1632,7 @@ int mingw_kill(pid_t pid, int sig) | |||
| */ | |||
There was a problem hiding this comment.
On the Git mailing list, Jeff King wrote (reply to this):
On Fri, Feb 15, 2019 at 07:17:45AM -0800, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin <[email protected]>
>
> Running up to v2.21.0, we fixed two bugs that were made prominent by the
> Windows-specific change to retain copies of only the 30 latest getenv()
> calls' returned strings, invalidating any copies of previous getenv()
> calls' return values.
>
> While this really shines a light onto bugs of the form where we hold
> onto getenv()'s return values without copying them, it is also a real
> problem for users.
>
> And even if Jeff King's patches merged via 773e408881 (Merge branch
> 'jk/save-getenv-result', 2019-01-29) provide further work on that front,
> we are far from done. Just one example: on Windows, we unset environment
> variables when spawning new processes, which potentially invalidates
> strings that were previously obtained via getenv(), and therefore we
> have to duplicate environment values that are somehow involved in
> spawning new processes (e.g. GIT_MAN_VIEWER in show_man_page()).
Belated review, as this is already in master, but: yes, I absolutely
support this patch, even on top of my patches. Those were just the cases
I found by poking around for a few minutes, and I'm sure there are many
more.
-Peff
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.
We saw a couple of getenv() cleanups, where we now immediately duplicate the return value of
getenv()in order to avoid problems. However, I am really uncomfortable with the current value (30) ofGETENV_MAX_RETAINincompat/mingw.c: it strikes me as low, given that the average number ofgetenv()call per Git process in Git's test suite is already 40.I'd really like to increase it, even if it won't help problems where
getenv()is called in a loop whose number of iteration depends on user input (like the problem fixed in 6776a84 (diff: ensure correct lifetime of external_diff_cmd, 2019-01-11)). It will still fend off plenty of other cases, I believe.And yes, it's in my TODOs to look back over those getenv() issues after v2.21.0 (see git-for-windows#2019 for my progress).