Re: Substitution ${...///} slows down when certain UTF character occurs

[Bart Schaefer <schaefer@brasslantern.com>]

On Sep 30,  3:04pm, Peter Stephenson wrote:
} Subject: Re: Substitution ${...///} slows down when certain UTF character 
}
} In some complex git completion --- reproducible only in one set up ---
} the heap allocation is apparently going out of bounds.  Yet I've checked
} and nothing seems able to happen that can affect this.  If I add
} debugging, the same pointer is reported as returned from zhalloc() that
} is later claimed to be out of bounds.  Yet with more debugging there's
} no popheap() or switch_heap() happening, as by eye there can't be.  I'm
} a bit stuck; how can a piece of memory returned by zhalloc() suddenly go
} invalid?
} 
} valgrind agrees with gdb but doesn't give any more help.

Did you --enable-zsh-heap-debug and --enable-zsh-valgrind ?  I always
forget at least the latter of those ...

} Maybe we're just running out of memory after all?

That seems really unlikely, unless the explicit zalloc version shows a
similar issue.  But I suppose if the heap is never popped it might be
possible to run out of memory on a deep recursive glob.  Perhaps a
call to freeheap() is needed somewhere prior to the popheap()?  Or
maybe there *is* a freeheap() happening where it isn't any longer safe
to do so -- did you check for that?

Even if out of memory, I wouldn't expect an existing pointer to go bad.
You'd just fail to get a new one.  And heaps are mmap()d if possible so
in that case you'd have to be out of address space, not just out of
memory?