[Boost-bugs] [Boost C++ Libraries] #9224: rapidxml, memory corruption in class memory_pool, private member m_static_memory; not threadsafe in multi-threaded process

Subject: [Boost-bugs] [Boost C++ Libraries] #9224: rapidxml, memory corruption in class memory_pool, private member m_static_memory; not threadsafe in multi-threaded process
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2013-10-10 21:26:36

#9224: rapidxml, memory corruption in class memory_pool, private member
m_static_memory; not threadsafe in multi-threaded process
-------------------------------------------------+-------------------------
 Reporter:  spacecabooie@…                       |      Owner:  cornedbee
     Type:  Bugs                                 |     Status:  new
Milestone:  To Be Determined                     |  Component:
  Version:  Boost 1.54.0                         |  property_tree
 Keywords:  rapidxml, memory_pool,               |   Severity:  Showstopper
  allocate_node, m_static_memory, multi-         |
  threaded                                       |
-------------------------------------------------+-------------------------
 Symptom: Executing on a mips under VxWorks 6.8 (though not when executing
 on a PC under Windows 7, compiled under VSC++), a simple three-four branch
 deep XML <string, string> file of more than 10-12 lines in length causes a
 call to property_tree/read_xml(istream, pt) to fail with Signal 11
 (Segmentation Fault).

 Cause: Debugging analysis shows that the failure occurs due to
 memory_pool::allocate_node() returning an invalid node_type to its parser
 caller.  The returned value should be identical to the value provided in
 the call, but instead of being 0, 1, 2, 4 (doc, data, etc.) as passed in
 at construction (placement new), the returned value may be 681123, or some
 other value invalid as a node type.

 Debugging further, within allocate_node(), by repeatedly printing in
 succession (up to 6-7 times) the local value of node_type, one will
 observe that the value becomes invalid on the 3rd or 4th print. (There are
 no other instructions within this thread being executed between the printf
 statements.)  Debugging even further, by repeatedly printing an an entire
 region of the m_static_memory array, from m_begin to m_ptr, one will
 observe significant portions of this entire region changing in value.

 Thus, another thread is writing into this area.  The threads within the
 process all share the memory reserved/partitioned to this process.
 However, should one not expect that the m_static_memory array will be
 declared on the stack, or that otherwise the m_static_memory array address
 space will be resolved by the linker to be occupied exclusively by
 memory_pool ?

 '''Apparently not. Perhaps this design is only for single threaded
 applications.'''

 Possible (non-optimal) solution: To resolve the memory overlap and
 resulting susceptibility to corruption, I moved the declaration of the
 private data member m_static_array outside of the memory_pool class, and
 in fact outside of all namespace encapsulation present in rapidxml.hpp; it
 is now a global variable.

 This does not crash. But neither is it boost conforming.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/9224>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.