3 ms·

The article spoke about a suspected memory leak in setenv(), I assume it uses uClibc but it was a bit light on the details (no source code links in the article,

by unwind 12y ago

The article spoke about a suspected memory leak in setenv(), I assume it uses uClibc but it was a bit light on the details (no source code links in the article, that I could find). I dug up this link: http://git.uclibc.org/uClibc/tree/libc/stdlib/setenv.c?id=308bd3f7988e13267b67c7a17c36ba2ad92b3c1c#n50 http://git.uclibc.org/uClibc/tree/libc/stdlib/setenv.c?id=30... which I believe is the relevant function. Unsurprisingly for this level of library code, it's not 100% super-obvious or easy to understand. Especially the details on the in-library memory management are unknown to me, but I thought it might be interesting.

SixSigma 12y ago
> Unsurprisingly for this level of library code, it's not 100% super-obvious or easy to understand. Sounds like you visit the wrong libraries. Try plan9's
dfox 12y ago
The whole putenv()/setenv()/unsetenv()/environ API is inconsistent hack that is essentially impossible to implement without introducing memory leak in at least one of these operations without introducing some complex additional book keeping. The good news is that there aren't that many reasons to actually use these functions, as only reasonable usecase for modifying environment is changing environment of spawned subprocesses, which can be done by constructing your own environ and passing it as envp argument to exec(). On the other hand the memory leak is mostly negligible and one would assume that for reasonable program that calls setenv (ie. does not call setenv in a loop) probably smaller than cost of the aforementioned extra book keeping.
- bigmessowires 12y ago
  I used the older uC-libc, not the newer uClibc (no dash in the name). You're right. There's a tiny leak in this version of setenv(), when you set a value for an environment var that already exists. It leaks the old value, which seems to be an intentional design choice, in case anything was holding on to a pointer to it.

by unwind 12y ago

SixSigma 12y ago

> Unsurprisingly for this level of library code, it's not 100% super-obvious or easy to understand. Sounds like you visit the wrong libraries. Try plan9's

dfox 12y ago

The whole putenv()/setenv()/unsetenv()/environ API is inconsistent hack that is essentially impossible to implement without introducing memory leak in at least one of these operations without introducing some complex additional book keeping. The good news is that there aren't that many reasons to actually use these functions, as only reasonable usecase for modifying environment is changing environment of spawned subprocesses, which can be done by constructing your own environ and passing it as envp argument to exec(). On the other hand the memory leak is mostly negligible and one would assume that for reasonable program that calls setenv (ie. does not call setenv in a loop) probably smaller than cost of the aforementioned extra book keeping.

bigmessowires 12y ago
I used the older uC-libc, not the newer uClibc (no dash in the name). You're right. There's a tiny leak in this version of setenv(), when you set a value for an environment var that already exists. It leaks the old value, which seems to be an intentional design choice, in case anything was holding on to a pointer to it.