>
>
> >
> > 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