3 ms·
Doesn’t the essay contradict itself? It states that glibc “never free[s] environment variables], but then goes on to state > [in glibc] if a thread calling se
by masklinn 3y ago
Doesn’t the essay contradict itself?
It states that glibc “never free[s] environment variables], but then goes on to state
> [in glibc] if a thread calling setenv() needs to resize the array of pointers, it copies the values to a new array and frees the previous one
Since envvars cause crash under glibc, I assume the initial assertion is incorrect.
- Tobu 3y agoThere are two level of pointers: the environment block points to an array of pointers to C strings, this higher-level pointer can be updated and the previous one freed, which is a problem when it is being iterated on (which getenv does). The C strings themselves aren't freed by glibc, though some applications do modify them in place.
- masklinn 3y agoOIC, so because glibc doesn't hold the setenv lock during lookup a concurrent getenv can break, but once getenv has found an entry that entry is guaranteed to be valid (unless the application plays silly bugger) because setenv will not free the individual entries.