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

[Kjell Ahlstedt <kjell ahlstedt bredband net>]

I made a quick attempt to find the source code of libxml++ in Red Hat Enterprise Linux Server release 6.1, but I failed.

The segfaults from SaxParser occurred in a std::map. When you said that you didn't find any map in the source code, did you look in libxml++/parsers/parser.cc, or did you look only in the header files? If parser.cc contains
  std::map<const xmlpp::Parser*, ExtraParserData> extra_parser_data;
but does not contain
  Glib::Threads::Mutex extra_parser_data_mutex;
then you've got a version of libxml++ where SaxParser is not thread-safe.

If you haven't got the complete source code of libxml++, there is one other thing you can do, provided you haven't updated libxml++ since you got the segfaults almost half a year ago: Check which version of libxml++ you are using:

  pkg-config --modversion libxml++-2.6

If it's 2.35.1, 2.35.2, or 2.35.3, you've got a version with a known bug which makes it thread-unsafe. The bug has been fixed in later versions.
https://bugzilla.gnome.org/show_bug.cgi?id=681467

I'm not really sure this is a foolproof way to check which version of libxml++ you've got. I don't know if Red Hat make their own fixes before they release it as part of their Linux distribution.

Kjell

2013-04-06 15:52, Aleksei Artemiev skrev:

Hi, Kjell,

  So long mail delay...I have no idea how came to that. Just FYI: I've migrated to TextReader immediately and it seems to be very stable. I will not dig deeper now for this problem, but just hope TextReader is okay at this moment. We already near Ready For Service stage of our product and I have no any issues with with libxml++ now.
  Sometimes people panic and this has happened to me, so I was needed a support and good advice. )))
  Anyway, thanks for the answer!
  FYI: we used rhel 6.1 and I think we upgraded to latest libxml for sax parser. I have no idea what was the root cause and my code analysis did not bring any results. If you will find out something-someday related - this will be interesting to know.
  Also, during migration to TextReader I found <node end> analysis very confusing, but you might know what I am talking about.

  Thanks again!

Alex.

2013/2/7 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