I am sorry if this is a stupid question, or simply inappropriatie for this list. I am currently camping with this bug for way too long, so I decided to ask this mailinglist.
I am currently in the process of finding out where a segfault is, and how to fix it. Now, I am using the boost regex library to parse my regexes, and for some reason when multiple threads use this regex library, it seems to mess up and generate segfaults (it works perfectly with only one thread). Since it also doesn't always occur on the same place, and doesn't even occur /all/ the times, I have a strong feeling this has something to do with thread safety.
On the Boost website is was able to find out that the boost regex library should be thread safe when BOOST_HAS_THREADS is defined; I've tested this, and this worked. ( http://www.boost.org/libs/regex/doc/thread_safety.html )
However, I also was able to find a mailinglist message that provides some instructions on how to make certain boost regex functions thread-safe : ( http://lists.boost.org/MailArchives/boost/msg59110.php )
Now, I am confused; is the boost regex library thread-safe or not ? The solution provided in the mailinglist message ( move the regex_replace () function inside its own scope ) can't be applied here... :(
I've posted the stacktrace when the problem occurs and the source of the code 'that matters' below. It also occurs in another function, I've posted the other function too. I hope anyone has any experience with this, or is able to help.
Regex is thread safe in following sense: given a const regex object, you can safely share that object between multiple threads. However, your backtrace indicates that the problem occurs during regex construction: this is a situation *you* have to deal with (no matter what the data type), the thread safety guarantees only kick in once the object has been constructed, it's up to you to ensure that no race condition occurs during the construction. Your second link above indicates a couple of methods you could use to achieve this. Regards, John.