boost正则表达式构造函数中的互斥断言 我使用Boost 1.47，用代码源C++编译器（4.5.1），从Windows 7交叉编译为目标Ubuntu。

编译调试版本（即启用断言）时，会触发断言：

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

在发布模式下编译时，不会触发断言，程序工作正常（据我们所知）

这是在Ubuntu 10.x Arm板下发生的

因此，pthread_mutex_锁似乎认为互斥锁是由与当前线程不同的线程设置的。此时在我的程序中，我们仍然是单线程的，在调用regex构造函数之前，通过在main中打印pthread_self进行验证。也就是说，它不应该使断言失败

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

// 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

模板化代码为：

// 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;
}

我使用这些偏移量来检查内存中的数据。这些值没有意义： 例如，

\uuu data.\uu lock

字段（一个int）是0xb086b580。

\u计数

（无符号整数）为0x6078af00，

\u所有者

（整数）为0x6078af00

这使我想到，不知何故，这个互斥体的初始化没有执行。或者它已经完全损坏，但我倾向于错过初始化，因为当我链接调试boost库时，没有断言

现在，我假设无论查询的是什么互斥体，都是用于使regex线程安全的全局/静态互斥体，并且不知何故它没有初始化

• 有人遇到过类似的情况吗？Ubuntu是否需要一些额外的步骤来确保互斥初始化
• 我的实现假设正确吗
• 如果它是正确的，有人能告诉我这个互斥锁是在哪里声明的，它的初始化是在哪里发生的吗
• 对进一步的调试步骤有什么建议吗？我想我可能不得不下载源代码并在其中重建跟踪（希望StackOverflow能在我到达这一点之前帮助我）

我使用这些偏移量来检查内存中的数据。这些值没有意义： 例如，

\uuu data.\uu lock

字段（一个int）是0xb086b580。

\u计数

（无符号的>整数）为0x6078af00，

\u所有者

（整数）为0x6078af00

这听起来好像代码的不同部分对各种结构应该有多大有不同的看法。一些需要检查的事项：

• 是否有任何

  #define

  可以放大数据结构，但在整个代码库中设置不一致？（在Windows上，

  \u SECURE\u SCL

  因此类漏洞而臭名昭著）
• 你们做结构包装吗？如果您在头中的任何位置设置了

  #pragma pack

  ，但忘记在头的末尾取消设置，则其后包含的任何数据结构的布局都将与程序中的其他位置不同

---

在一个众所周知的、经过良好测试的库（如boost）中，当出现一个非常特别的运行时崩溃时，首先要检查的是是否存在头/库配置不匹配。IMHO，将_DEBUG或NDEBUG放在头文件中，特别是在结构中，以影响其二进制布局的方式，是一种反模式。理想情况下，无论我们定义_DEBUG、DEBUG、DEBUG、DEBUG、NDEBUG或其他什么，我们都应该能够使用相同的.lib（这样我们就可以根据是否需要调试符号来选择.lib，而不是根据它是否匹配头定义）。不幸的是，情况并非总是如此。

如果我不得不猜测的话，互斥锁在共享指针实现中。您是否有可能使用“valgrind”之类的工具来查看是否存在损坏底层数据的内存损坏？是否可以使用更简单的RE来解决问题？用一个很短的程序和同样的RE？用一个简短的程序和一个简短的回复？当错误发生时，堆栈会是什么样子？它是源于main还是之前的版本？valgrind是个好主意，但是在使用它之前，你能尝试使用pthread_mutex_init显式地初始化互斥锁吗？同样，正如Yakk暗示的，你能不能编写一个简单的程序来解决同样的问题？请参阅文章的第一行：boost 1.47中的ArmNo pragma包等等。顺便说一句，因为锁（我怀疑是静态文件范围）在boost代码中，我假设我的代码不会做任何事情来重新排列这个锁。这是问题所在，但在boost的代码中，不是我的。是的，这确实是问题所在。我在构建我的源代码时启用了调试，它利用了各种定义，例如调试，但链接到非调试库。我广告（虚假）假设调试库和非调试库之间的唯一区别是代码没有优化，并且存在调试信息。这种假设根深蒂固，我从未想过在问题的原始帖子中包含我的链接或编译行。但是，boost中的结构布局似乎在调试之间发生了变化我不知道这是否是真正的罪魁祸首，但在boost/xpressive/detail/core/regex_impl.hpp中，我在struct regex_impl中看到有一个整型字段

静态int实例

，由

ifdef boost\u xpressive\u debug\u CYCLE\u TEST

保护。

// 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;
}

/* 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;