Re: BUG: useheap in doexpandhist()

["Barton E. Schaefer" <schaefer@xxxxxxxxxxxxxx>]

On Jun 24,  9:11pm, Zoltan Hidvegi wrote:
} Subject: Re: BUG: useheap in doexpandhist()
}
} > } 	BUG: useheap in doexpandhist()
} > 
} > I've gotten it several more times now, always in completion but not always
} > in the name of a function.  I can't yet isolate any preceding usages that
} > trigger it.  It may have something to do with that TMOUT=10 TRAPALRM that
} > I posted a few days ago.

Of course I was thinking 10 *minutes* -- that should say TMOUT=600.

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

} About the patch below: Peter suggested a stack for permalloc()/lastalloc().
} This is not a bad idea but maybe it's not the best.  In most places of the
} code either only permanent or only heap allocation is valid.  Also almost
} always ncalloc, alloc, dupstrig are used to get space from the heap.  The
} most important exeptions are the various dup*** routines and the routines
} for creating new structures.  Perhaps a better solution is to use
} halloc()/hcalloc() where the heap should be used and define a new function
} as a replacement for dupstring() which always uses the heap.  An other
} solution is using heapalloc()/permalloc() in all cases where the state of
} the allocation is unknown or know to be wrong.

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.

} And does anyone know the historical reason why ncalloc refers to
} halloc/zalloc and alloc refers to hcalloc/zcalloc?  This is exactly the
} opposite of the logical behaviour.

It's been that way since before I started fooling with zsh, so I'm
willing to bet the only person who knows is Paul F.

-- 
Bart Schaefer                     Vice President, Technology, Z-Code Software
schaefer@xxxxxxxxxx                   Division of NetManage Corporation
http://www.well.com/www/barts           http://www.ncdsoft.com/ZMail/