Boost logo

Boost Users :

From: Andriy Tylychko (mail.ru) (telya_at_[hidden])
Date: 2006-06-16 03:10:03


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.

 



Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net