I'm having a problem with RapidXML 1.12 on Solaris 10 with GCC 3.4.3. The following code triggers a segfault:
#include "rapidxml.hpp"
int main()
{
using namespace rapidxml;
xml_document<> doc;
// OK
{
char* s = doc.allocate_string("abc");
xml_node<>* n = doc.allocate_node(node_element, "123");
}
// SIGSEGV
{
char* s = doc.allocate_string("ab");
xml_node<>* n = doc.allocate_node(node_element, "123");
}
return 0;
}
... and here's the stack trace from GDB:
Program received signal SIGSEGV, Segmentation fault.
0x00011660 in xml_base (this=0xffbef9f7) at rapidxml.hpp:623
623 {
(gdb) bt
#0 0x00011660 in xml_base (this=0xffbef9f7) at rapidxml.hpp:623
#1 0x000111cc in xml_node (this=0xffbef9f7, type=rapidxml::node_element) at rapidxml.hpp:867
#2 0x00011060 in rapidxml::memory_pool<char>::allocate_node (this=0xffbef9b0, type=rapidxml::node_element, name=0x116c0 "123",
value=0x0, name_size=0, value_size=0) at rapidxml.hpp:412
#3 0x00010d28 in main () at test_rapidxml.cpp:18
The above example works just fine when compiled with Sun Studio so it's not clear to me whether it's a bug in GCC or RapidXML.
Any ideas?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
RapidXML allocator currently does not attempt to align allocations in any way. If you allocate a string with some odd length, and then allocate a node, some pointers and integers of the node may be weirdly alignened in the memory.
On x86 this does not cause a crash.
I don't know about your architecture (is it a PowerPC)?
It may likely require that pointers are aligned to 4 bytes, or something like that.
What i do not understand is why compiling with another compiler makes it work?
If alignment is the problem, the solution is to add alignment support to memory_pool. This has long been planned but I have not had time to implement it yet.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The server is equipped with SPARC processors. It indeed looks like an alignment problem because I found that I can also generate a crash with the Sun C++ compiler by controlling its alignment assumptions and runtime behavior with the -xmemalign option:
If I specify that a SIGSEGV should be generated for access to misaligned data then only a 1-byte alignment assumption will do (-xmemalign=1s). Apparently the default setting for the installed Sun C++ compiler is to simply trap the signal and continue execution.
Unfortunately I haven't been able to figure out how to tell GCC how to relax its alignment assumptions. It seems this is not supported for SPARC targets.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The new RapidXML 1.13 should solve your problem (if you haven't solved it already). It has now proper support for alignment, and should not cause any more crashes.
In case of any problems remaining on your platform you can tweak RAPIDXML_ALIGNMENT to match the requirements (it defaults to size of pointer).
Thanks,
Marcin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm having a problem with RapidXML 1.12 on Solaris 10 with GCC 3.4.3. The following code triggers a segfault:
#include "rapidxml.hpp"
int main()
{
using namespace rapidxml;
xml_document<> doc;
// OK
{
char* s = doc.allocate_string("abc");
xml_node<>* n = doc.allocate_node(node_element, "123");
}
// SIGSEGV
{
char* s = doc.allocate_string("ab");
xml_node<>* n = doc.allocate_node(node_element, "123");
}
return 0;
}
... and here's the stack trace from GDB:
Program received signal SIGSEGV, Segmentation fault.
0x00011660 in xml_base (this=0xffbef9f7) at rapidxml.hpp:623
623 {
(gdb) bt
#0 0x00011660 in xml_base (this=0xffbef9f7) at rapidxml.hpp:623
#1 0x000111cc in xml_node (this=0xffbef9f7, type=rapidxml::node_element) at rapidxml.hpp:867
#2 0x00011060 in rapidxml::memory_pool<char>::allocate_node (this=0xffbef9b0, type=rapidxml::node_element, name=0x116c0 "123",
value=0x0, name_size=0, value_size=0) at rapidxml.hpp:412
#3 0x00010d28 in main () at test_rapidxml.cpp:18
The above example works just fine when compiled with Sun Studio so it's not clear to me whether it's a bug in GCC or RapidXML.
Any ideas?
The crash occurs in constructor of xml_base:
xml_base()
: m_name(0)
, m_value(0)
, m_parent(0)
{
}
Alignment problem?
RapidXML allocator currently does not attempt to align allocations in any way. If you allocate a string with some odd length, and then allocate a node, some pointers and integers of the node may be weirdly alignened in the memory.
On x86 this does not cause a crash.
I don't know about your architecture (is it a PowerPC)?
It may likely require that pointers are aligned to 4 bytes, or something like that.
What i do not understand is why compiling with another compiler makes it work?
If alignment is the problem, the solution is to add alignment support to memory_pool. This has long been planned but I have not had time to implement it yet.
Thanks Marcin!
The server is equipped with SPARC processors. It indeed looks like an alignment problem because I found that I can also generate a crash with the Sun C++ compiler by controlling its alignment assumptions and runtime behavior with the -xmemalign option:
http://docs.sun.com/source/819-3690/Comp_Options_App.html#pgfId-1012560
If I specify that a SIGSEGV should be generated for access to misaligned data then only a 1-byte alignment assumption will do (-xmemalign=1s). Apparently the default setting for the installed Sun C++ compiler is to simply trap the signal and continue execution.
Unfortunately I haven't been able to figure out how to tell GCC how to relax its alignment assumptions. It seems this is not supported for SPARC targets.
Hi Lars,
The new RapidXML 1.13 should solve your problem (if you haven't solved it already). It has now proper support for alignment, and should not cause any more crashes.
In case of any problems remaining on your platform you can tweak RAPIDXML_ALIGNMENT to match the requirements (it defaults to size of pointer).
Thanks,
Marcin
Version 1.13 seems to work. Thanks!