On Tue, Apr 18, 2017 at 4:03 PM, Mark Wielaard <m...@klomp.org> wrote: > 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 <m...@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.
Hmmm, well, OK for stage 1, I guess. Ian
