https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87675
--- Comment #4 from N1705695H at e dot ntu.edu.sg --- (In reply to Scott Gayou from comment #3) > My last comment was a bit confusing. I can reproduce 2/3 on a standard > system, and the other 1/3 requires dropping ulimit -s down a bit. (to 4096). Hi， I don't think you've made a clear analysis of the problem. This has nothing to do with how much stack memory you set up. No matter how big your stack memory is, it can still run out. The test case only give a small number of characters. As you can imagine, you can still run out of memory by giving a lot of characters. In detail, the program requires the amount of resource such as time, memory, power, etc. Memory exhaustion problems in the server can occur circumstantially when programs are provided with inputs that exhibit worst-case behavior. However, the high space complexity of the algorithm or poorly-designed programs consume much more memory than necessary under well-conceived inputs. In particular, stack memory is very limited. An attacker may use own function call or multiple functions to call each other, exhausting stack memory. In other words, no matter how large your stack memory is, it will always run out(by given more "Z" or "U"). No matter how big you set it up, it's ultimately limited. The problem itself is very difficult to fix. The problem is that C++ mangled names have a recursive structure. Simple restriction cycles are not necessarily good. Moreover, these examples give different stack frames. This is cause by giving different string input. Some are call itself. Some are call different function. In fact, it's hard to set recursive limits on every function. Recursion limit would not fix all of these hence they are different root cause(Loop calls involving six functions in a finite function stack frame).
