id summary reporter owner description type status milestone component version severity resolution keywords cc 9224 rapidxml, memory corruption in class memory_pool, private member m_static_memory; not threadsafe in multi-threaded process spacecabooie@… Sebastian Redl "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 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." Bugs closed To Be Determined property_tree Boost 1.54.0 Showstopper worksforme rapidxml, memory_pool, allocate_node, m_static_memory, multi-threaded