Problems with Solaris + gcc 3.4.3

[Lars Hannelius]

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?

[mack]

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.

[Lars Hannelius]

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.

[mack]

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

[Lars Hannelius]

Version 1.13 seems to work. Thanks!