Re: emacs-24.3: test request

[Matthias Scheler <tron%zhadum.org.uk@localhost>]

On Mon, Sep 09, 2013 at 11:05:20AM +0100, Matthias Scheler 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.
> > > 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.

I've committed a fix earlier:

----- Forwarded message from Matthias Scheler <tron%netbsd.org@localhost> -----

Module Name:    src
Committed By:   tron
Date:           Mon Sep  9 10:21:28 UTC 2013

Modified Files:
        src/lib/libc/stdlib: _env.c

Log Message:
Don't scrub the environment unless we are going to change it. This should
prevent crashes in applications which carefully and manually construct
a temporary environment and later restore the original environment
like Emacs 24.

Problem reported by Thomas Klausner on "pkgsrc-users" mailing list.


To generate a diff of this commit:
cvs rdiff -u -r1.7 -r1.8 src/lib/libc/stdlib/_env.c

----- End forwarded message -----

I would appreciate if somebody who could reproduce the original problem
could try this fix.

        Kind regards

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