Why does std::regex_iterator cause a stack overflow with this data?

Question

I\'ve been using std::regex_iterator to parse log files. My program has been working quite nicely for some weeks and has parsed millions of log lines, until to

Answer 1

The regex appears to be OK; at least there is nothing in it that could cause catastrophic backtracking.

I see a small possibility to optimize the regex, cutting down on stack use:

static wregex rgx_log_lines(
    L"^L(\\d+)\\s+"             // Level
    L"T(\\d+)\\s+"              // TID
    L"(\\d+)\\s+"               // Timestamp
    L"\\[([\\w:]+)\\]"          // Function name
    L"((?:"                     // Complex pattern
      L"(?!"                    // Stop matching when...
        L"^L\\d"                // New log statement at the beginning of a line
      L")"                      
      L"[^]"                    // Matching all until then
    L")*)"                      // 
    );

Did you set the ECMAScript option? Otherwise, I suspect the regex library defaults to POSIX regexes, and those don't support lookahead assertions.

Answer 2

Negative lookahead patterns which are tested on every character just seem like a bad idea to me, and what you're trying to do is not complicated. You want to match (1) the rest of the line and then (2) any number of following (3) lines which start with something other than L\d (small bug; see below): (another edit: these are regexes; if you want to write them as string literals, you need to change \ to \\.)

 .*\n(?:(?:[^L]|L\D).*\n)*
 |   |  |
 +-1 |  +---------------3
     +---------------------2

In Ecmascript mode, . should not match \n, but you could always replace the two .s in that expression with [^\n]

Edited to add: I realize that this may not work if there is a blank line just before the end of the log entry, but this should cover that case; I changed . to [^\n] for extra precision:

 [^\n]*\n(?:(?:(?:[^L\n]|L\D)[^\n]*)?\n)*