[Python-Dev] Re: various test failures - test_site, test_tempfile, test_bsddb/anydbm

[Skip Montanaro]

    >> It seems that the string posix_putenv() is passing to putenv() is
    >> properly allocated.

    Tim> It is, but "new" is embedded inside a Python string object:

    Tim>        new = PyString_AS_STRING(newstr);

    Tim> A realloc(new) call would be insane (new isn't an address returned
    Tim> by malloc; newstr is the address that was returned by malloc).

Agreed.  I grabbed the Darwin libc source from Apple which corresponds to
the version of Mac OS X I'm running.  The only realloc() call in
stdlib/setenv.c is to realloc the entire environment.  The environment
pointer is a funny beast.  It starts out not in malloc'd storage but has to
be malloc'd if it needs to be resized:

        static int alloced;                     /* if allocated space before */
        ...
        char ***environp = _NSGetEnviron();

        ...
                register int cnt;
                register char **p;

                for (p = *environp, cnt = 0; *p; ++p, ++cnt);
                if (alloced) {                  /* just increase size */
                        *environp = (char **)realloc((char *)*environp,
                            (size_t)(sizeof(char *) * (cnt + 2)));
                        if (!*environp)
                                return (-1);
                }
                else {                          /* get new space */
                        alloced = 1;            /* copy old entries into it */
                        p = malloc((size_t)(sizeof(char *) * (cnt + 2)));

I stepped through the raw machine code in gdb.  The alloced variable gets
set properly (0 the first time through, then the space is malloc'd and
alloced is set to 1).  On the third call to setenv() the malloc_printf call
is triggered.

    Tim> But if it's not trying to realloc(new), then new is a red herring,
    Tim> and the platform has gotten its pointers into the environment
    Tim> structure screwed up.  That could be due to a wild store anywhere
    Tim> (platform, Python, whatever).

*sigh* That seems to be the case.  I haven't the energy to pick over machine
code to find out where "anywhere" is...

Skip