Re: emacs-24.3: test request

[Steffen "Daode" Nurpmeso <sdaoden%gmail.com@localhost>]

Matthias Scheler <tron%zhadum.org.uk@localhost> wrote:
 |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.
 |> 
 |> 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
 
FYI, POSIX documents `environ' in the execve(2) family section:

  Applications can change the entire environment in a single
  operation by assigning the environ variable to point to an array
  of character pointers to the new environment strings.

  After assigning a new value to environ, applications should not
  rely on the new environment strings remaining part of the
  environment, as a call to getenv(), [XSI]  putenv(),  setenv(),
  unsetenv(), or any function that is dependent on an environment
  variable may, on noticing that environ has changed, copy the
  environment strings to a new array and assign environ to point to
  it.

  Any application that directly modifies the pointers to which the
  environ variable points has undefined behavior.

 |-- 
 |Matthias Scheler                                  http://zhadum.org.uk/

--steffen

--- Begin Message ---

• To: current-users%NetBSD.org@localhost
• Subject: Re: emacs-24.3: test request
• From: Matthias Scheler <tron%zhadum.org.uk@localhost>
• Date: Mon, 9 Sep 2013 11:05:20 +0100

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/

--- End Message ---