Skip to content
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

Make getenv thread-safe #191

Merged
merged 4 commits into from
Dec 20, 2024
Merged

Make getenv thread-safe #191

merged 4 commits into from
Dec 20, 2024

Conversation

Flamefire
Copy link
Collaborator

In order to return a non-owning pointer without memory leaks the function needs to use a static variable.
When calling it from multiple threads there is a data race during the assignment (and conversion) to this variable.
Fix by making it thread_local.

Fixes #189

@Flamefire Flamefire force-pushed the get-env-thread branch 11 times, most recently from d96b3cf to ce96657 Compare December 8, 2024 18:49
In order to return a non-owning pointer without memory leaks the
function needs to use a static variable.
When calling it from multiple threads there is a data race during the
assignment (and conversion) to this variable.
Fix by making it `thread_local`.

Fixes #189
Using `bash` puts `/mingw64/bin` first in the path but the compiler from
`/c/mingw64/bin` is used.
This leads to errors running the tests: "Exit code 0xc0000139" (DLL issue)
which are related to the use of `thread_local`.
Using the powershell works in all cases.
@Flamefire Flamefire force-pushed the get-env-thread branch 5 times, most recently from be14349 to ab5d22a Compare December 19, 2024 18:44
There is a bug in GCC for 32bit MinGW until version 11.
This causes a use-after free for destruction of `thread_local` variables
that crash the application when the destructor accesses any member.
In the tests it shows up as exit code/status `-1073741819` i.e. `0xC0000005`.
Workaround this by not destructing the `stackstring` instance used to
hold the value of the last `getenv` result.
In the case where any call to `getenv` of a thread yielded a large
value heap memory will be allocated and not freed due to this missing
destructor call causing a memory leak, possibly for each thread.
However values up to some length are stored on stack memory and hence
the missing destructor call does not cause a memory leak as the type is
essentially trivial in this state.

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83562
Fixed by https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=7fc0f78c3f43af1967cb7b1ee8f4947f3b890aa2
Copy link

codecov bot commented Dec 20, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.47%. Comparing base (1423d15) to head (b9ff85d).
Report is 5 commits behind head on develop.

Additional details and impacted files
@@           Coverage Diff            @@
##           develop     #191   +/-   ##
========================================
  Coverage    99.47%   99.47%           
========================================
  Files           34       34           
  Lines         3460     3460           
========================================
  Hits          3442     3442           
  Misses          18       18           
Files with missing lines Coverage Δ
src/cstdlib.cpp 91.66% <100.00%> (ø)

@Flamefire Flamefire merged commit 9c673c0 into develop Dec 20, 2024
84 checks passed
@Flamefire Flamefire deleted the get-env-thread branch December 20, 2024 13:36
github-actions bot pushed a commit that referenced this pull request Dec 20, 2024
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.

GetEnv is hazardous when used in multiple threads
1 participant