John Maddock wrote:

Ø       You shouldn't get that exception from that expression: that exception is
raised when the number of states visted in the search for a match looks to
be growing exponentially, it's usually caused by "pathological" regular
expressions like "(.*)*" that can end up searching forever on some inputs.

Do you have a more specific test case please?

John.

Ø        

 

Hi John.

 

Thanks for quick reply. I’m afraid I don’t have more specific test. Maybe additional info will help.

 

Boost v.1.33.1, VC 8.0. The buffer content looks like:

 

00:00:00.000 [category 100] EXCEPTION: test log-message #100
00:00:00.000 [category 101] ERROR: test log-message #101
new line
00:00:00.000 [category 102] WARNING: test log-message #102
00:00:00.000 [category 103] INFO: test log-message #103
00:00:00.000 [category 104] DEBUG: test log-message #104
00:00:00.000 [category 105] EXCEPTION: test log-message #105
new line
00:00:00.000 [category 106] ERROR: test log-message #106

[...]

00:00:00.000 [category 300] EXCEPTION: test log-message #300

 

As result, threre's no match for "#1.*#7" in such content. Debugger shows that regex_search reached position "171\r\n00:00:00.000 [category 172] WARNING: test log-message #172[...]", state_count = 468663, max_state_count = 468640.

 

Can I provide any additional useful info? Should I send you standalone test for problem reproduction?

 

Thank you,

Andriy.

 

John Maddock wrote:

> Andriy Tylychko (mail.ru) wrote:
>> Hi,
>>
>> The code looks like:
>>
>> std::string buffer(10240, '\0');
>> // ... fill buffer
>> boost::regex e("#1.*#7");
>> boost::smatch m;
>> boost::regex_search(buffer, m, e);
>>
>> The buffer of 10KB is full of "something #x". As result I receive
>> regex_constants::error_space at
>> boost\regex\v4\perl_matcher_non_recursive.hpp:164.
>> I'll highly appreciate any help.
>
> You shouldn't get that exception from that expression: that exception is
> raised when the number of states visted in the search for a match looks to
> be growing exponentially, it's usually caused by "pathological" regular
> expressions like "(.*)*" that can end up searching forever on some inputs.
>
> Do you have a more specific test case please?
>
> John.