Databases
StackOverflow2013
Postsdbo
POMutex assert in boost regex constructor
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POMutex assert in boost regex constructor
    primarykey
    data
    text
    <p>I'm using boost 1.47 for Arm, with the Code Sourcery C++ compiler (4.5.1), crosscompiling from Windows 7 targeting Ubuntu.</p> <p>When we compile the debug version (i.e. asserts are enabled), there is an assert triggered:</p> <pre><code>pthread_mutex_lock.c:62: __pthread_mutex_lock: Assertion 'mutex-&gt;__data.__owner == 0' failed. </code></pre> <p>Compiling in release mode, the assert is not triggered and the program works fine (as far as we can tell). </p> <p>This is happening under a Ubuntu 10.x Arm board.</p> <p>So, it appears that the pthread_mutex_lock thinks the mutex was set by a different thread than the current one. At this point in my program, we're still single threaded, verified by printing out pthread_self in main and just before the regex constructor is called. That is, it should not have failed the assertion.</p> <p>Below is the snippet of code that triggers the problem.</p> <pre><code>// Set connection server address and port from a URL bool MyHttpsXmlClient::set_server_url(const std::string&amp; server_url) { #ifdef BOOST_HAS_THREADS cout &lt;&lt;"Boost has threads" &lt;&lt; endl; #else cout &lt;&lt;"WARNING: boost does not support threads" &lt;&lt; endl; #endif #ifdef PTHREAD_MUTEX_INITIALIZER cout &lt;&lt; "pthread mutex initializer" &lt;&lt; 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 // &lt;-- dies in here </code></pre> <p>I've confirmed that BOOST_HAS_THREADS is set, as is PTHREAD_MUTEX_INITIALIZER.</p> <p>I tried following the debugger though boost but it's templated code and it was rather difficult to follow the assembly, but we basically die in do_assign (roughtly line 380 in basic_regex.hpp)</p> <pre><code>basic_regex&amp; assign(const charT* p1, const charT* p2, flag_type f = regex_constants::normal) { return do_assign(p1, p2, f); } </code></pre> <p>the templated code is:</p> <pre><code>// 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 &lt;class charT, class traits&gt; basic_regex&lt;charT, traits&gt;&amp; basic_regex&lt;charT, traits&gt;::do_assign(const charT* p1, const charT* p2, flag_type f) { shared_ptr&lt;re_detail::basic_regex_implementation&lt;charT, traits&gt; &gt; temp; if(!m_pimpl.get()) { temp = shared_ptr&lt;re_detail::basic_regex_implementation&lt;charT, traits&gt; &gt;(new re_detail::basic_regex_implementation&lt;charT, traits&gt;()); } else { temp = shared_ptr&lt;re_detail::basic_regex_implementation&lt;charT, traits&gt; &gt;(new re_detail::basic_regex_implementation&lt;charT, traits&gt;(m_pimpl-&gt;m_ptraits)); } temp-&gt;assign(p1, p2, f); temp.swap(m_pimpl); return *this; } </code></pre> <p>I'm not sure what component is actually using the mutex--does anyone know?</p> <p>In the debugger, I could retrieve the address for the variable <code>mutex</code> and then inspect (<code>mutex-&gt;__data.__owner</code>). I got the offsets from the compiler header file bits/pthreadtypes.h, which shows:</p> <pre><code>/* 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; </code></pre> <p>I used these offsets to inspect the data in memory. The values did not make sense: For instance, the <code>__data.__lock</code> field (an int) is 0xb086b580. The <code>__count</code> (an unsigned int) is 0x6078af00, and <code>__owner</code> (an int) is 0x6078af00.</p> <p>This leads me to think that somehow initialization of this mutex was not performed. Either that or it was completely corrupted, but I'm leaning to missed initialization because when I linked with debug boost libraries, there was no assert.</p> <p>Now, I'm assuming that whatever mutex that is being queried, is some global/static that is used to make regex threadsafe, and that somehow it was not initialized.</p> <ul> <li>Has anyone encountered anything similar? Is there some extra step needed for Ubuntu to ensure mutex initialization?</li> <li>Is my implementation assumption correct?</li> <li>If it is correct, can someone point me to where this mutex is declared, and where it's initialization is occurring</li> <li>any suggestions on further debugging steps? I'm thinking I might have to somehow download the source and rebuild with tracing in there (hoping StackOverflow can help me before I get to this point)</li> </ul>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USQuuxplusone
    1. USTheDuke
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POMutex assert in boost regex constructor
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POMutex assert in boost regex constructor
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POMutex assert in boost regex constructor
      1. This table or related slice is empty.
      1. VTUpMod
    1. COIf I had to guess, the mutex is inside the shared pointer implementation. Is there any possibility that you can use something like 'valgrind' to see if there is some memory corruption damaging the underlying data?
      singulars
      1. POMutex assert in boost regex constructor
      1. USDave S
    2. COCan you get the problem to occur with a simpler RE? With a really short program and the same RE? With a short program and a short RE? When the error happens, whatt dies your stack look like? Is it rooted at main or is it before that?
      singulars
      1. POMutex assert in boost regex constructor
      1. USYakk - Adam Nevraumont
    3. COvalgrind is a good idea, but before using it, could you try to initialize the mutex explicitely using pthread_mutex_init?
      singulars
      1. POMutex assert in boost regex constructor
      1. USdidierc
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload