Re: [PATCH] libiberty: Limit demangler maximum d_print_comp recursion call depth.

["Ian Lance Taylor via gcc-patches" <gcc-patches at gcc dot gnu dot org>]

On Tue, Apr 18, 2017 at 4:03 PM, Mark Wielaard <mark@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 <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.

Hmmm, well, OK for stage 1, I guess.

Ian