>> 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4