On Mon, Sep 09, 2013 at 09:03:29AM +0100, Matthias Scheler wrote: > > > On the other hand, is there any "official" documentation that says that > > > what emacs is doing is allowed? > > > > The exact behaviour of the environment vector is not very documented. > > And there are lot of implementations with various incorrect behaviours > > like putenv(3) on older version of NetBSD. > > > > If the garbage collection code causes problems it should be removed. > > On a second thought I think that "emacs" is indeed broken. The scrubbing > of the environment is not the only problem it can trigger. If it sets > "environ" to its own array and calls e.g. setenv(3) it can also > trigger this case in "src/lib/libc/stdlib/_env.c" if the new environment > vector is full. > > /* Allocate a new environment array. */ > if (environ == allocated_environ) { > [...] > } else { > free(allocated_environ); > allocated_environ = NULL; > allocated_environ_size = 0; > [...] > } > > So by the time "emacs" restores the original pointer "libc" might have > freed the memory it points to.
Looking at emacs's code it seems to carefully avoid that by creating a large enough environment vector and copying all the contents. I think the problem can be avoided by never scrubbing the environment within calls to getenv(3). I'm currently testing such a change. Kind regards -- Matthias Scheler http://zhadum.org.uk/