Re: [PATCH] Set DEMANGLE_RECURSION_LIMIT to 1536

[Jason Merrill <jason at redhat dot com>]

On Mon, Dec 10, 2018 at 1:55 PM Jakub Jelinek <jakub@redhat.com> wrote:
>
> On Mon, Dec 10, 2018 at 10:20:24AM -0800, Ian Lance Taylor wrote:
> > > I think it is a bad idea to use the same macro and value for both the
> > > recursion limit and essentially stack limit.  For the latter, it should
> > > actually compute expected stack size
> > > (i.e. di.num_comps * sizeof (*di.comps) + di.num_subs * sizeof (*di.subs))
> > > and rather than just giving up should say that memory up to 64KB this
> > > way will be handled via alloca, more through say mmap (I'd avoid malloc
> > > because some users are using these APIs in cases where malloc isn't usable).
> > > And have only much larger limit, like say 1MB for these arrays on which to
> > > give up.
> >
> > That makes sense.
> >
> > We've wanted to avoid malloc in this code because some programs call
> > the demangler from a signal handler.  But using mmap should be fine in
> > practice.
>
> mmap is not available everywhere, but we could just have a smaller limit
> on how big mangled names we handle on targets where mmap isn't available or
> if it fails.
>
> And, the other option is just try to parse the string without doing all the
> processing first and compute (perhaps upper bound) on how many components
> and substitutions we need.  Many components have longish names, or numbers,
> etc. so the 2 * strlen is really very upper bound and strlen for number of
> substitutions too.

Or, in that situation, we could put an upper bound on the number of
components and substitutions, and fail if we end up needing more than
that.

Jason