[Bug binutils/25180] Slowness in cplus_demangle()

[nickc at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=25180

Nick Clifton <nickc at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #3 from Nick Clifton <nickc at redhat dot com> ---
Hi Tim,

> Smaller and 'real-world' input may have the same issue just on a much
> smaller scale - so I wonder if this an 'easy-to-fix' code flaw or an 'fixed'
> design (flaw).

I would say both... see below.

> You sound like this is a well-known behavior of the demangler and nothing
> can be done. If that is the case, then sorry for not knowing. Feel free to
> close the issue :-)

Well, it is a well known issue, but something could be done.

The cause of the problem is basically due to the recursive nature of name
mangling, and there is nothing that can be done about this.  But there is a
built-in recursion limit in the demangling code which is intended to catch
cases like this one.  It is controlled by the value of DEMANGLE_RECURSION_LIMIT
which is defined in demangle.h.  Currently this value is set to 2048, which was
chosen because it does not break any of the existing demangling tests.  But in
theory itcould be smaller.

For example, if you change the value 20 and rebuild, then your test case
returns in less than one second.  (The string is not demangled, because the
limiter just stops the operation of the library function, but cpu resources are
not hogged either).

I did try changing the value to 1024, but this allowed the test case to have
its slow down effect, and it is already known that 1024 prevents some real
world name demangling from working, so it looks like there is no easy cure for
this
particular test.  (I did consider making the limit definable via a command line
option, but this would involve a lot of changes to the libiberty library and
the tools that use it, and in the end an attacker would just disable it).

So I am sorry, but I think that in this case there is nothing that we can do.

Cheers
  Nick

-- 
You are receiving this mail because:
You are on the CC list for the bug.