Re:Don't setenv in multi-threaded code on glibc
by bonzini on Tuesday January 31, 2017 @06:53AM
(#13529768)
That is irrelevant. FreeBSD getenv doesn't protect accesses to the event with a lock, meaning that getenv will access a freed copy of the environment if a concurrent call to putenv resizes the underlying array. Musl has the same issue.
[ Parent
| on HN ]
Re:Don't setenv in multi-threaded code on glibc
by Sanddancer on Tuesday January 31, 2017 @04:27PM
(#13535412)
It uses a lock-free method of ensuring that there aren't segfaults. When it needs to move a variable because it's gotten too big, it copies it to the new location and sets the pointer accordingly with the old location flagged as old. The old variable isn't freed, so there are no dangling pointers, with the downside of memory usage being increased some.
Re:Don't setenv in multi-threaded code on glibc
by bonzini on Tuesday January 31, 2017 @04:52PM
(#13535586)
Doesn't it just use realloc? See __rebuild_environ in https://github.com/freebsd/freebsd/blob/master/lib/libc/stdl...