Run-time problem with VC6, stlport and boost (1.32) regex
Hi, I'm getting this runtime error in my program. c:\stlport-4.6.2\stlport\stl\debug\_iterator.h(179): STL assertion failure : __check_same_owner(__x, __y) The code that causes this is like this (Actual code slightly modified). It is the access of the match that triggers the error above. boost::smatch m; if (regex_match(s, m, reg)) { (here)--> s_info.version = m[1]; } I'm using stlport 4.6.2 with boost-1.32 on W2K and VC6 SP6. stlport is built with default options and boost is built like this: boost-jam-3.1.10-1-ntx86/bjam.exe -sTOOLS=msvc-stlport -sSTLPORT_PATH="c:" -sSTLPORT_VERSION=4.6.2 -sBUILD="debug release <runtime-link>static <threading>multi <stlport-iostream>on" install Any idea what can be wrong? Surely a simple access of the resulting match shouldn't cause this type of assertion to fire (or is there some subtle bug in my program that I'm missing!?) Please note that the program works OK using boost without stlport. Yours -- %% Mats
I'm getting this runtime error in my program.
c:\stlport-4.6.2\stlport\stl\debug\_iterator.h(179): STL assertion failure : __check_same_owner(__x, __y)
The code that causes this is like this (Actual code slightly modified). It is the access of the match that triggers the error above.
boost::smatch m; if (regex_match(s, m, reg)) { (here)--> s_info.version = m[1]; }
I'm using stlport 4.6.2 with boost-1.32 on W2K and VC6 SP6. stlport is built with default options and boost is built like this:
I regularly test with that compiler/std lib combination so it shouldn't be an issue.
Any idea what can be wrong? Surely a simple access of the resulting match shouldn't cause this type of assertion to fire (or is there some subtle bug in my program that I'm missing!?)
I suspect that you are creating a std::string from the sub_match? If so then STLport will validate the iterator range during the strings constructor, so a failure there is theoretically possible, but of course should never really happen. I don't really know what to suggest, can you post a test case? One thing to double check before you do: make sure that the iterators held by the match_results structure haven't been invalidated by your code: destroying the string to which they refer, or passing a temporary to regex_match would cause it. John.
John Maddock wrote:
I suspect that you are creating a std::string from the sub_match? If so then STLport will validate the iterator range during the strings constructor, so a failure there is theoretically possible, but of course should never really happen.
I don't really know what to suggest, can you post a test case?
Yes. See the code below.
One thing to double check before you do: make sure that the iterators held by the match_results structure haven't been invalidated by your code: destroying the string to which they refer, or passing a temporary to regex_match would cause it.
This test case fails in the described way. It seems to be because I use a smatch when an cmatch should be used instead!? With no stlport this (kind of) code works fine. ----------------------------------------------------------------- using namespace std; using namespace boost; void test_regex() { char const * s_line = "String"; boost::smatch m; if (regex_match(s_line, m, regex(".*"))) { string s = m[1]; } } int main() { test_regex(); return 0; } ----------------------------------------------------------------- Yours -- %% Mats
participants (2)
-
John Maddock
-
Mats Lidell