This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] libiberty: Limit demangler maximum d_print_comp recursion call depth.
On Tue, Apr 18, 2017 at 03:40:05PM -0700, Ian Lance Taylor wrote:
> On Tue, Apr 18, 2017 at 3:23 PM, Mark Wielaard <mark@klomp.org> wrote:
> > The fix for PR demangler/70909 and 67264 (endless demangler recursion)
> > catches when a demangle_component is printed in a cycle. But that doesn't
> > protect the call stack blowing up from non-cyclic nested types printed
> > recursively through d_print_comp. This can happen by a (very) long mangled
> > string that simply creates a very deep pointer or qualifier chain. Limit
> > the recursive d_print_comp call depth for a d_print_info to 1K nested
> > types.
> >
> > libiberty/ChangeLog:
> >
> > * cp-demangle.c (MAX_RECURSION_COUNT): New constant.
> > (struct d_print_info): Add recursion field.
> > (d_print_init): Initialize recursion.
> > (d_print_comp): Check and update d_print_info recursion depth.
>
> I'm probably missing something, but this kind of seems like an
> arbitrary limit. It's possible to imagine a rather unlikely valid
> symbol that will no longer be demangled. Why do we want to do this?
> What bug are we fixing?
It is an arbitrary limit and I am happy to change it if it is unrealistic.
I thought 1K was small enough that if we hit it we wouldn't have blown up
the call stack yet. But big enough that it is unlikely that it would be a
valid symbol (with that large a number of nested component types). The bug
we fix with this is a program trying to demangle a string that looks like
e.g. _Z3fnGGGGGGOGGGGGGGGGGGGGGGGGGG.... crashing because of stack overflow.
Cheers,
Mark