Re: libxml++ crashes (sigfault), need assistance, please

[Kjell Ahlstedt <kjell ahlstedt bredband net>]

2012-11-28 10:01, Aleksei Artemiev skrev:
> Hi and sorry for disturbance!
>
>   We are using libxml++ in a SOAP server/recever and in a mediation 
> platform. I observer xml++ crahes and I cannot get rid of that major 
> issue. Here comes ldconfig output:
>
> [root OCSPRODFE03 workflowProcess]# ldconfig -v | grep xml
> ldconfig: Path `/lib64' given more than once
>         libxmlrpc.so.3 -> libxmlrpc.so.3.16
>         libxmlrpc_abyss.so.3 -> libxmlrpc_abyss.so.3.16
>         libxml++-2.6.so.2 -> libxml++-2.6.so.2.0.7
>         libxmlrpc_server_cgi.so.3 -> libxmlrpc_server_cgi.so.3.16
>         libxmlrpc_server.so.3 -> libxmlrpc_server.so.3.16
>         libxmlrpc_client.so.3 -> libxmlrpc_client.so.3.16
>         libxmlrpc_server_abyss.so.3 -> libxmlrpc_server_abyss.so.3.16
>         libxml2.so.2 -> libxml2.so.2.7.6
>         libxmlrpc_util.so.3 -> libxmlrpc_util.so.3.16
>
> The platform is:
> Red Hat Enterprise Linux Server release 6.1 (Santiago)
>
> Core dump:
> Thread 41 (Thread 0x7fffcf986700 (LWP 9144)):
> #0  0x0000003fb186a06f in std::_Rb_tree_insert_and_rebalance(bool, 
> std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, 
> std::_Rb_tree_node_base&) ()
>    from /usr/lib64/libstdc++.so.6
> #1  0x00007ffff1127da3 in ?? () from /usr/lib64/libxml++-2.6.so.2
> #2  0x00007ffff1127fdd in ?? () from /usr/lib64/libxml++-2.6.so.2
> #3  0x00007ffff1128824 in xmlpp::Parser::initialize_context() () from 
> /usr/lib64/libxml++-2.6.so.2
> #4  0x00007ffff112ac4b in xmlpp::SaxParser::parse_chunk_raw(unsigned 
> char const*, unsigned int) () from /usr/lib64/libxml++-2.6.so.2
> #5  0x00000000006bd0cd in mediation::XMLCodec::decodeBuffer 
> (this=0x242f800, buffer=
>     "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<soapenv:Envelope 
> xmlns:soapenv=\"http://www.w3.org/2003/05/soap-envelope\ 
> <http://www.w3.org/2003/05/soap-envelope%5C>">\n <soapenv:Header 
> />\n   <soapenv:Body>\n <INByPassSubscribeProductResultMsg xmlns"..., 
> external_params=<value optimized out>) at ../../..
> ------------------------------------
>
> We use many threads which have private sax parser object and call for 
> parse_chunk for every new SOAP request or mediation event, so 
> initialize_context is called pretty often (could be 500 times in a 
> second). I did not find yet any maps objects in the sources which 
> could be static or whatever. Probably, we have to stick to the latest 
> parser versions. I am asking for help/advice as I cannot find anything 
> related in the www and cannot clarify the reason of the crash.
>
> I will recall this message if this issue will be cleared in the 
> meantime. Thanks in advance!
>
> PS. SOAP decoding will be changed to parse_memory call as we always 
> receive complete SOAP messages.
>
> Alex.
It seems your post to libxmlplusplus-list was sent 2012-11-28, but it 
arrived only today (2013-02-07)! Aren't you a member of 
libxmlplusplus-list? Could that be the reason for the long long delay?

A local std::map was added to libxml++/libxml++/parsers/parser.cc in the 
git repository 2012-01-30, commit
http://git.gnome.org/browse/libxml++/commit/?id=a6ac0b12f2574570f101450b880329eba7cfd6f2

Then it was noticed that the map was used in a way that was not 
thread-safe. So a Glib::Threads::Mutex was added to protect all accesses 
to the std::map, 2012-08-28, commit
http://git.gnome.org/browse/libxml++/commit/?id=e662e32f2943ef1b71101ccb1a9e7a0b585c39a2

Between those two commits there was no stable release of libxml++. But 
it's not impossible that your Linux distribution contains a version of 
libxml++ with the std::map, but without the protecting Mutex. I don't 
think you can be sure that every Linux distribution is based on stable 
releases of every included package.

When you say that you don't find any map in the source code, are you 
sure you look at exactly the version of the source code that has been 
compiled into the libxml++ library that you execute?

Kjell