[xpressive] sporadic crashes in multi-threaded code
Hello *, I face some issue with sporadic crashes in xpressive which I think a result of a race condition. The use case is: a function which needs to parse smth create local regex objects: const sregex any_char = _; sregex const& rdelim = parser_->delimiter(); //some dynamic delimiter token const sregex re_prefix = bos >> (s1=-*by_ref(any_char)) >> *(s2=by_ref(rdelim)) >> eos ; calling this function from multiple threads results in a crash with (boost 1.42, gcc 4.3.5 on debian linux). I previously had more crashes, but moved all regex objects to global space as const objects and they seem to be fine now. This is the only place I left with a local regex. In the stack trace it seems like internals of the local object regex are freed via boost weak_ptr with possible double delete attempt. The stack-trace of the created core-dump during the crash can be accessed via: https://docs.google.com/open?id=0BzJl1eEH-CCGODU5N2JhOTAtNWMxMy00OGNhLThhNzc... (Did not want to send addional 200k to the mailing list.) Many thanks for help, Ovanes
On 1/12/2012 6:29 AM, Ovanes Markarian wrote:
Hello *,
I prefer Eric, but hey. ;-)
I face some issue with sporadic crashes in xpressive which I think a result of a race condition. The use case is:
a function which needs to parse smth create local regex objects:
const sregex any_char = _; sregex const& rdelim = parser_->delimiter(); //some dynamic delimiter token
I'm going to guess that parser_->delimiter() returns an sregex object that is either global or held within parser_, is that right?
const sregex re_prefix = bos >> (s1=-*by_ref(any_char)) >> *(s2=by_ref(rdelim)) >> eos ;
calling this function from multiple threads results in a crash with (boost 1.42, gcc 4.3.5 on debian linux). I previously had more crashes, but moved all regex objects to global space as const objects and they seem to be fine now. This is the only place I left with a local regex.
In the stack trace it seems like internals of the local object regex are freed via boost weak_ptr with possible double delete attempt.
Yep, I know the problem. I'm sorry to say that it's by design -- or rather, that it's a known limitation of the way regex impls are ref-counted and would be very hard to fix, if it can be fixed at all. At least it's documented, but you'd have to read the docs very carefully. See here: http://www.boost.org/doc/libs/1_48_0/doc/html/xpressive/user_s_guide.html#bo... You're nesting regex objects; i.e., building a grammar. When you are building a grammar, both the outer *and* inner regex objects are modified. What is happening is that the sregex object (presumably) held by parser_ is being mutated simultaneously from several threads. That's bad. That link tells you that you need to build your grammars on a single thread. I would create this regex once the same place where you build the regex returned by parser_->delimiter(). Then use that regex instead of constructing it at local scope over and over. HTH, -- Eric Niebler BoostPro Computing http://www.boostpro.com
Hello Eric!
On Sat, Jan 14, 2012 at 5:35 AM, Eric Niebler
On 1/12/2012 6:29 AM, Ovanes Markarian wrote:
Hello *,
I prefer Eric, but hey. ;-)
I thought someone else could answer the question as well... So it was not
a special question for you ;) Because I know, that you spend considerable amount of time to maintain all your libs, so asking you directly to answer the post is a bit unpolite IMO ;) But many thanks for that answer.
Yep, I know the problem. I'm sorry to say that it's by design -- or rather, that it's a known limitation of the way regex impls are ref-counted and would be very hard to fix, if it can be fixed at all. At least it's documented, but you'd have to read the docs very carefully. See here:
http://www.boost.org/doc/libs/1_48_0/doc/html/xpressive/user_s_guide.html#bo...
You're nesting regex objects; i.e., building a grammar. When you are building a grammar, both the outer *and* inner regex objects are modified. What is happening is that the sregex object (presumably) held by parser_ is being mutated simultaneously from several threads. That's bad.
That link tells you that you need to build your grammars on a single thread. I would create this regex once the same place where you build the regex returned by parser_->delimiter(). Then use that regex instead of constructing it at local scope over and over.
HTH,
Yes, this is what I did by using Nifty Counter, even static initialization was not enough in my context, since there was some logger thread in a huge fw which did "bad things" when main was left and cause the application crash at exit. Many thanks for your great answer and verification of my assumption. Ovanes
participants (2)
-
Eric Niebler -
Ovanes Markarian