This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Handling stack overflow in <regex>


On 15/08/15 11:49 -0700, Tim Shen wrote:
Hi,

Currently we got 3 bugs about stack overflow due to the deep recursion
<regex> loads.

Boost specifically implemented a non-recursive engine, which manually
maintain a heap allocated C++ container as a storage stack to
implement backtracking. The disadvantages are 1) less readable code,
and 2) less efficient code, since manual stack can't benefit from
compiler optimizations (e.g. inlining) as much.

I assume libgcc is a mandatory dependency of libstdc++, since
std::thread uses gthr.h.

I propose to use POSIX makecontext-like semantic to create a new fixed
configurable sized stack, and run the same recursive code on this
stack happily ever after :). When this stack is exhausted (we can
periodically check the stack consumption in regex), throw a
regex_constants::error_stack.

I find context switching related code in libgcc's generic-morestack.c.
It targets -fsplit-stack, but split stack is just too heavy for us. I
plan to pull out makecontext/swapcontext primitives and use them
directly.

I don't know if POSIX makecontext/swapcontext is a choice, but that is
less efficient and deprecated
(http://www.boost.org/doc/libs/1_58_0/libs/context/doc/html/context/rationale/other_apis_.html),
and boost implements its own.

I assume this also makes implementing stackless resumable function easier.

Is this plausible? Should I contact someone (e.g. Ian)?

I have no idea how plausible it is, but it sounds complicated.

Weren't you just going to use a dynamically-allocated container
instead of recursive function calls?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]