> > > > > > It's changed since then. If you have HAVE_PUTENV defined in config.h, try > > undefining it for something a bit more like (but not identical to) the old > > behaviour to see if that makes a difference. > > > > I believe, I know what happens. When zsh creates parameters from > environment, > it splits env string in-place; Well, it turned out to be not directly related. What actually happens is, when zsh initially (in creatparamtable) gets env string for predefined colon array it finally calls colnarrsetfn that unconditionally calls arrfixenv(). This one does not even check if variable is exported but simply tries to replace environment string with replenv() that tries to free previous environment string ... that resides somewhere in global memory. After we looped over env's all is clean again - every env string was allocated by Zsh. But the above simply happens too early. Ironically, when Zsh did not copy original env strings it appeared to work (but who knows, what memory corruption could it cause). But when I wrote a patch to copy original string, zsh started to crash. I do not know, if it was my fault or was there before. I probably have not changed usage of replenv() bit may have changed it's semantic. Anyway, as is stands now, there seems to be no point in having it at all - either variable is exported and has PM_EXPORTED set or it is not exported and does not have this flag. If it is not true, something is seriously broken anyway. So, this patch removes all replenv() usage with checking for PM_EXPORTED and addenv(). I still removed env string in-place modification just in case. Koen, could you test if it helps? It appears to work here, but so did unmodified Zsh as well. I appreciate, if anybody could review memory allocation usage here - I still do not grok completely Zsh memory usage. The patch is against current CVS. -andrej
Attachment:
zsh.replenv.diff
Description: Binary data