• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Code-gen bugs compile Boost Regex with gcc/XCode Obj-C++ (3.1).
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Code-gen bugs compile Boost Regex with gcc/XCode Obj-C++ (3.1).


  • Subject: Code-gen bugs compile Boost Regex with gcc/XCode Obj-C++ (3.1).
  • From: Tom Titchener <email@hidden>
  • Date: Fri, 26 Sep 2008 17:06:05 -0400


Compiling with -Os caused problems with offsets from "this" to member data for different routines in the the parse_extended routine vs. the parse_literal. If anybody knows a way to compile boost regex with objective-c++ then I'd like to hear about it, please. Otherwise, read below to see what our experience and work-around.


Looking at the member offsets in the assembly and in the debugger for parent class basic_regex_creator you can see the faulty code (in parse_literal) adds a four-byte pad before 64-bit member m_bad_repeats. There's no pad in the caller routine parse_extended, so when parse_literal goes to use member data like m_position, located in higher memory than m_bad_repeats, it finds and tries to dereference invalid pointer values like 1 and 0. Here's what the call stack looked like:

#0 0x0001456c in boost::re_detail::basic_regex_parser<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::parse_literal at basic_regex_parser.hpp:339
#1 0x000a451e in boost::re_detail::basic_regex_parser<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::parse_extended at basic_regex_parser.hpp:320
#2 0x000a151a in boost::re_detail::basic_regex_parser<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::parse_all at basic_regex_parser.hpp:180
#3 0x000a151a in boost::re_detail::basic_regex_parser<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::parse_open_paren at basic_regex_parser.hpp:389
#4 0x000a43ac in boost::re_detail::basic_regex_parser<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::parse_extended at basic_regex_parser.hpp:250
#5 0x000a33fd in boost::re_detail::basic_regex_parser<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::parse_all at basic_regex_parser.hpp:180
#6 0x000a33fd in boost::re_detail::basic_regex_parser<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::parse at basic_regex_parser.hpp:132
#7 0x000a34d1 in boost::re_detail::basic_regex_implementation<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::assign at basic_regex.hpp:103
#8 0x0009b3fc in boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::do_assign at basic_regex.hpp:531
#9 0x00011913 in boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::assign at basic_regex.hpp:262
#10 0x0001a575 in boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::basic_regex at basic_regex.hpp:216


Here's the code that generated the access violation. Member m_position was set to value 1, so dereferencing it didn't work very well:

if(
((this->flags()
& (regbase::main_option_type|regbase::mod_x| regbase::no_perl_ex))
!= regbase::mod_x)
|| !this->m_traits.isctype(*m_position, this->m_mask_space))
this->append_literal(*m_position);


Compiling with -O2, like in the boost Mac makefile "solved" this problem, but ran caused the regex code to throw error_space after failing this comparison at line 175 of perl_matcher_non_recursive.hpp because max_state_count was zero, which looks like a similar sort of problem:

            if(state_count > max_state_count)
               raise_error(traits_inst, regex_constants::error_space);

The work-around was to create a simple wrapper API that called the Boost regex code and export it from a context compiled strictly with c+ + and not objective-c++. Even then we ran into some confusion due to a second code path in a different c++ file that happened to #include <boost/regex.hpp> and compile some regex code, even though the call paths never traversed this branch. The active code path went through the new API, but we still got the same code-generation problems, probably because the names the objective-c++ code created for the inactive branch superseded the names for the c++ code created as part of the library compile from the c++ context. Once we conditionally- compiled out the inactive path so the objective-c++ compiler (well, "the" compiler with its objective-c++ hat), then we were finally able to call into boost regex, even with -O2 optimization.

Part of what's confusing is all this code works fine built debug. But if you want release mode code that reaches from objective-c++ into boost regex, then then you'll need independent compile contexts: objective-c++ for objective c++, c++ for boost regex (at least with XCode 3.1).

Unless somebody else has a way to make this work. Otherwise we're facing some refactoring work down the road....



_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Prev by Date: Re: XCode/gdb won't break
  • Next by Date: Re: Working-around a Symbol Conflict
  • Previous by thread: Re: Working-around a Symbol Conflict
  • Next by thread: include behavior of Xcode and gcc via comnd line differ.
  • Index(es):
    • Date
    • Thread