Re: BUG: useheap in doexpandhist()

[Zoltan Hidvegi <hzoli@xxxxxxxxxx>]

> } Unfortunately there are some zsh functions which are not reentrant which
> } cause problems when a signal comes.
> 
> In the case I suspect, though, all zsh should have been doing when the
> signal arrived was sitting idle at the PS1 prompt.  The signal is not
> arriving during the completion, as far as I can tell; rather, the heap
> allocation has already been left in a confused state, and trying the
> completion just happens to be what makes zsh notice the bad state.
> 
> Is that what your patch was intended to fix?

Yes.  The signal trap can leave the allocation in some undefined state.  My
patch just makes sure that after executiong the trap the original
allocation state is restored.

> Yes, the right thing to do is to eliminate the global pointers to alloc
> functions, and call the desired ones directly.  The pointers were used
> in the first place so some utility routines (like dupstring) could be
> written once and then be used regardless of whether heap or permanent
> allocation was desired.  The zsh heap, in turn, is just a crude garbage
> collection mechanism, as I'm sure you're aware.
> 
> Unfortunately, at this point there are probably so many routines that
> depend on having this memory management magically handled for them, that
> it'd be as big a change to fix that as to make everything reentrant.

I think that the heap used in zsh is very useful.  It is convinient, it
certainly guarantees that there is no memory leak if the heap is used and
it is efficient since instead of calling malloc()/free() frequently we call
these only a few times.  This can make things faster since malloc()/free()
can be very expensive if sbrk()/brk() is called.  Once I played with the
Linux ypserv and I found that it spends most of its time in sbrk/brk in
some situations.  Then I linked it with the malloc from zsh with the brk
staff removed and it become much faster than before.

Zoltan