互斥体在boost regex构造函数中声明

我使用ARM的boost 1.47,Code Sourcery C ++编译器(4.5.1),针对Ubuntu的Windows 7进行交叉编译。

当我们编译debugging版本(即断言被启用)时,会触发一个断言:

pthread_mutex_lock.c:62: __pthread_mutex_lock: Assertion 'mutex->__data.__owner == 0' failed. 

在释放模式下编译,assert没有被触发,程序工作正常(据我们所知)。

这是在Ubuntu 10.xarm板下发生的。

所以,似乎pthread_mutex_lock认为互斥体是由与当前不同的线程设置的。 在我的程序中的这一点上,我们仍然是单线程的,通过在main中打印出pthread_self并在调用正则expression式构造函数之前进行validation。 也就是说,它不应该断言断言。

下面是触发问题的代码片段。

 // Set connection server address and port from a URL bool MyHttpsXmlClient::set_server_url(const std::string& server_url) { #ifdef BOOST_HAS_THREADS cout <<"Boost has threads" << endl; #else cout <<"WARNING: boost does not support threads" << endl; #endif #ifdef PTHREAD_MUTEX_INITIALIZER cout << "pthread mutex initializer" << endl; #endif { pthread_t id = pthread_self(); printf("regex: Current threadid: %d\n",id); } const boost::regex e("^((http|https)://)?([^:]*)(:([0-9]*))?"); // 2: service, 3: host, 5: port // <-- dies in here 

我已经确认BOOST_HAS_THREADS被设置,PTHREAD_MUTEX_INITIALIZER也是如此。

我尝试了下面的debugging器虽然提升,但它是模板化的代码,并且很难跟随程序集,但我们基本上死在do_assign(在basic_regex.hpp中为380行)

 basic_regex& assign(const charT* p1, const charT* p2, flag_type f = regex_constants::normal) { return do_assign(p1, p2, f); } 

模板代码是:

 // out of line members; // these are the only members that mutate the basic_regex object, // and are designed to provide the strong exception guarentee // (in the event of a throw, the state of the object remains unchanged). // template <class charT, class traits> basic_regex<charT, traits>& basic_regex<charT, traits>::do_assign(const charT* p1, const charT* p2, flag_type f) { shared_ptr<re_detail::basic_regex_implementation<charT, traits> > temp; if(!m_pimpl.get()) { temp = shared_ptr<re_detail::basic_regex_implementation<charT, traits> >(new re_detail::basic_regex_implementation<charT, traits>()); } else { temp = shared_ptr<re_detail::basic_regex_implementation<charT, traits> >(new re_detail::basic_regex_implementation<charT, traits>(m_pimpl->m_ptraits)); } temp->assign(p1, p2, f); temp.swap(m_pimpl); return *this; } 

我不确定什么组件实际上使用互斥体 – 有谁知道?

在debugging器中,我可以检索variablesmutex的地址,然后检查( mutex->__data.__owner )。 我从编译器头文件位/ pthreadtypes.h得到偏移量,它显示:

 /* Data structures for mutex handling. The structure of the attribute type is not exposed on purpose. */ typedef union { struct __pthread_mutex_s { int __lock; unsigned int __count; int __owner; /* KIND must stay at this position in the structure to maintain binary compatibility. */ int __kind; unsigned int __nusers; __extension__ union { int __spins; __pthread_slist_t __list; }; } __data; char __size[__SIZEOF_PTHREAD_MUTEX_T]; long int __align; 

我用这些偏移来检查内存中的数据。 这些值没有意义:例如, __data.__lock字段(一个int)是0xb086b580。 __count (一个unsigned int)是0x6078af00, __owner (一个int)是0x6078af00。

这导致我认为这个互斥体的初始化没有被执行。 无论是它或它是完全损坏,但我倾向于错过初始化,因为当我与debugging增强库链接,没有断言。

现在,我假设无论是被查询的互斥量,是​​用于使正则线程安全的一些全局/静态,并且不知何故它没有被初始化。

  • 有没有人遇到类似的东西? 是否有一些额外的步骤需要Ubuntu确保互斥体初始化?
  • 我的实施假设是否正确?
  • 如果这是正确的,是否有人可以指向这个互斥体声明的位置,以及它正在发生初始化的地方
  • 任何进一步的debugging步骤的build议? 我想我可能不得不以某种方式下载源代码和在那里跟踪重build(希望StackOverflow可以帮助我之前,我到这一点)

首先要检查的是真正特别的运行时崩溃是否出现在一个众所周知的经过充分测试的库(如boost)中,是否存在头/库配置不匹配。 恕我直言,把_DEBUG或NDEBUG标题,特别是在影响其二进制布局的方式,是一种反模式。 理想情况下,无论我们是否定义_DEBUG,DEBUG,Debug, Debug ,NDEBUG或其他类型,我们都应该可以使用相同的.lib。这样我们就可以根据是否需要调试符号来选择.lib,匹配头部定义)。 不幸的是,情况并非总是如此。

我用这些偏移来检查内存中的数据。 这些值没有意义:例如, __data.__lock字段(一个int)是0xb086b580。 __count (一个无符号> int)是0x6078af00, __owner (一个int)是0x6078af00。

这听起来像你的代码的不同部分有不同的意见应该是多大的各种结构。 有些事情要检查:

  • 有没有放大数据结构的#define ,但是在整个代码库中没有一致的设置? (在Windows上, _SECURE_SCL是臭名昭着的这种类型的错误)
  • 你做任何结构包装? 如果在标题的任何位置设置#pragma pack ,并忘记在标题末尾取消设置,那么之后包含的任何数据结构将具有与程序中其他位置不同的布局。