fixes crash when debugging on xcode

[arturoc]

when running an application using this library from within xcode, it'll crash xcode. dividing the code like it's done in this patch fixes it.

this is mostly an update of cpp-netlib/cpp-netlib@f7c46ad for the new structure of the repo and should also fix: cpp-netlib/cpp-netlib#539

[glynos]

I'm sorry @arturoc, according to Travis, your changes break the tests on Linux. Can you take another look?

[deanberris]

@arturoc -- Thanks for this. Although I think that issue (cpp-netlib/cpp-netlib#539) is an issue against the 0.11-devel branch (not the uri library per se). And the previous attempt at fixing this also breaks in Linux, so I hope you can get around to addressing those failures here and in the 0.11-devel branch of cpp-netlib/cpp-netlib as well?

[arturoc]

mmh, yes. the problem i think is that this big chunk of code:

        ipv6address %= qi::raw
            [qi::repeat(6)[h16 >> ':'] >> ls32 |
             "::" >> qi::repeat(5)[h16 >> ':'] >> ls32 |
             -qi::raw[h16] >> "::" >> qi::repeat(4)[h16 >> ':'] >> ls32 |
             -qi::raw[h16] >> "::" >> qi::repeat(3)[h16 >> ':'] >> ls32 |
             -qi::raw[h16] >> "::" >> qi::repeat(2)[h16 >> ':'] >> ls32 |
             -qi::raw[h16] >> "::" >> h16 >> ':' >> ls32 |
             -qi::raw[h16] >> "::" >> ls32 | -qi::raw[h16] >> "::" >> h16 |
             -qi::raw[h16] >> "::" |
             -qi::raw[qi::repeat(1)[(h16 >> ':')] >> h16] >> "::" >>
                 qi::repeat(3)[h16 >> ':'] >> ls32 |
             -qi::raw[qi::repeat(1)[(h16 >> ':')] >> h16] >> "::" >>
                 qi::repeat(2)[h16 >> ':'] >> ls32 |
             -qi::raw[qi::repeat(1)[(h16 >> ':')] >> h16] >> "::" >> h16 >>
                 ':' >> ls32 |
             -qi::raw[qi::repeat(1)[(h16 >> ':')] >> h16] >> "::" >> ls32 |
             -qi::raw[qi::repeat(1)[(h16 >> ':')] >> h16] >> "::" >> h16 |
             -qi::raw[qi::repeat(1)[(h16 >> ':')] >> h16] >> "::" |
             -qi::raw[qi::repeat(2)[(h16 >> ':')] >> h16] >> "::" >>
                 qi::repeat(2)[h16 >> ':'] >> ls32 |
             -qi::raw[qi::repeat(2)[(h16 >> ':')] >> h16] >> "::" >> h16 >>
                 ':' >> ls32 |
             -qi::raw[qi::repeat(2)[(h16 >> ':')] >> h16] >> "::" >> ls32 |
             -qi::raw[qi::repeat(2)[(h16 >> ':')] >> h16] >> "::" >> h16 |
             -qi::raw[qi::repeat(2)[(h16 >> ':')] >> h16] >> "::" |
             -qi::raw[qi::repeat(3)[(h16 >> ':')] >> h16] >> "::" >> h16 >>
                 ':' >> ls32 |
             -qi::raw[qi::repeat(3)[(h16 >> ':')] >> h16] >> "::" >> ls32 |
             -qi::raw[qi::repeat(3)[(h16 >> ':')] >> h16] >> "::" >> h16 |
             -qi::raw[qi::repeat(3)[(h16 >> ':')] >> h16] >> "::" |
             -qi::raw[qi::repeat(4)[(h16 >> ':')] >> h16] >> "::" >> ls32 |
             -qi::raw[qi::repeat(4)[(h16 >> ':')] >> h16] >> "::" >> h16 |
             -qi::raw[qi::repeat(4)[(h16 >> ':')] >> h16] >> "::" |
             -qi::raw[qi::repeat(5)[(h16 >> ':')] >> h16] >> "::" >> h16 |
             -qi::raw[qi::repeat(5)[(h16 >> ':')] >> h16] >> "::" |
             -qi::raw[qi::repeat(6)[(h16 >> ':')] >> h16] >> "::"];

makes lldb crash in some versions of xcode 6.x. dividing it in chunks like in this PR fixes the crash but as you say breaks the tests. i guess it's a problem with operator priority? the code is so convoluted that it's really difficult to know what's going on and almost any attempt to factor out parts of that makes the tests incorrect.

[arturoc]

what if i ifdef'd this for clang so the current version is still compiled for gcc?

[glynos]

No ifdefs. I won't merge this.

[arturoc]

do you have any other idea about how to fix this? while the error in xcode seems to be a bug in lldb it would be good to have some kind of workaround otherwise the library can't be used in xcode. and the initial fix while compiling and passing the tests in clang makes the gcc compiled tests fail and even segfault

[glynos]

From what I understand, the issue you're having is because of a bug in your IDE. Otherwise, this code already works on Clang and MacOS without any problems.

Therefore, the correct thing to do would be to contact the developers of lldb.

I will close this issue now, because the proposed solution with the ifdef statements is not satisfactory. If you are able to workaround your IDE bug with a clean implementation in our library, I would be happy to take another look.

[arturoc]

Yes it's a bug in lldb or xcode. any project using this library will compile fine but when trying to run it from within xcode it'll crash it. in any case it's for sure a problem in the ide, not this library but i guess xcode is a very used IDE and it would be desirable to have some kind of workaround until it's fixed.

I myself use linux but develop a multiplatform project that most people in osx use from xcode, we've recently added your library to parse uris and it was crashing xcode. We've fixed it by patching the osx version and thought you might want to have a fix but don't have any idea of how to fix it without ifdefs: moving even the most minimal part of that code around will make the gcc generated code crash.

[glynos]

I am happy to hear you are using the uri in your project, but I am frustrated to hear that you can't use it because of the lldb issue. Does this prevent you and your team from using it?

[deanberris]

I think it should be possible to break up the parser into smaller chunks with its own named objects. This doesn't sound like an unreasonable approach.

Now I personally don't have time to do this myself, but doing this incrementally should be possible, no? We have Travis to check for test correctness in Linux, I suppose we should be able to keep an eye on this while we're iterating on the patch? Has anybody asked in the Spirit mailing lists for help on how to do this without breaking semantics?

[arturoc]

@glynos, we've solved this on our end by having our build system patch the osx version. i jiust thought that it might be good to have a workaround in the orinal repo given that xcode is a pretty standard IDE.

@deanberris i've tried that but the most minimal change in that code, even storing the whole thing in a variable and then doing the %= with the result, breaks the tests in gcc. also the results are mixed in release and debug, debug being somehow more robust so i wouldn't even trust the travis results on this.