You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-users@xalan.apache.org by Richard MARSOT <Ri...@nmss.com> on 2003/01/07 14:42:49 UTC
STL Multithreading issue under Sparc Solaris (gcc 2.95.3 - Xalan 1.3)
Hi,
I am using Xalan C 1.3 under Sparc Solaris with gcc 2.95.3.
In my program, I uses intensively the XalanDOMString class.
It appears that when I use two threads that both uses XalanDOMString
instances, my program core dumps after a while inside the STL library.
If I put mutex between the two threads averything just went fine.
I am struggling to understand if:
1/ this is a known issue in Xalan 1.3 that could have been corrected in 1.4
2/ or is it a known STL issue (not multithread safe under Solaris)
Should I use STLPORT to solve this issue ? If you can give me some advices
to fix this issue, I would really appreciate it.
Thanks a lot for your help.
Richard Marsot.
see below the core dump output
#0 0xfe8339b0 in less<NodeImpl *>::operator() (this=0x1536e4, __x
=@0xffbee358, __y=@0x730074)
at
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/stl_function.h:111
111 bool operator()(const _Tp& __x, const _Tp& __y) const { return
__x < __y; }
(gdb) bt
#0 0xfe8339b0 in less<NodeImpl *>::operator() (this=0x1536e4, __x
=@0xffbee358, __y=@0x730074)
at
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/stl_function.h:111
#1 0xfe8467ec in _Rb_tree<NodeImpl *, pair<NodeImpl *const, XalanNode *>,
_Select1st<pair<NodeImpl *const, XalanNode *> >, less<NodeImpl *>,
allocator<XalanNode *> >::insert_unique (this=0x1536dc, __v=@0xffbee358)
at
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/stl_tree.h:884
#2 0xfe846d1c in map<NodeImpl *, XalanNode *, less<NodeImpl *>,
allocator<XalanNode *> >::insert (this=0x1536dc, __x=@0xffbee358)
at
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/stl_map.h:162
#3 0xfe437a34 in XercesToXalanNodeMap::addAssociation (this=0x1536d0,
theXercesNode=@0xffbee4f0, theXalanNode=0x8d780)
at XercesParserLiaison/XercesToXalanNodeMap.cpp:97
#4 0xfe42488c in XercesDocumentBridge::createBridgeNode (this=0x1536c0,
theXercesNode=@0xffbee4f0, theIndex=0, mapNode=true)
at XercesParserLiaison/XercesDocumentBridge.cpp:408
#5 0xfe425560 in XercesDocumentBridge::createBridgeNode (this=0x1536c0,
theXercesNode=@0xffbee4f0, theIndex=0, mapNode=true)
at XercesParserLiaison/XercesDocumentBridge.cpp:807
#6 0xfe423b98 in XercesDocumentBridge::mapNode (this=0x1536c0,
theXercesNodeImpl=0x77f80)
at XercesParserLiaison/XercesDocumentBridge.cpp:187
#7 0xfe424240 in XercesDocumentBridge::mapNode (this=0x1536c0,
theXercesNode=@0xffbee5e0)
at XercesParserLiaison/XercesDocumentBridge.cpp:271
#8 0xfe428d10 in XercesDocumentBridge::getDocumentElement (this=0x1536c0)
at XercesParserLiaison/XercesDocumentBridge.cpp:1442
#9 0xff2f50e4 in omuSetProperty (doc={<DOM_Node> = { fImpl =
0x50928}, <No data fields>},
szQuery=0x236d8 "/Properties/Propagation/NumActiveAlarms",
szValue=0xffbee7d0 "1") at omu.cpp:2453
#10 0x19054 in omwSetProperty () at omu_unittest.cpp:195
#11 0x17e04 in main (argc=1, argv=0xffbee9dc) at omu_unittest.cpp:91
Re: STL Multithreading issue under Sparc Solaris (gcc 2.95.3 - Xalan 1.3)
Posted by David N Bertoni/Cambridge/IBM <da...@us.ibm.com>.
Hi Richard,
This could be a library issue with that version of the GCC compiler. You
could try the STLport library, but I don't have any experience using it on
Solaris with GCC, so I don't know if that will fix the problem or not. The
crash indicates you're in a routine where nodes for a std:map are being
allocated, and this is a common place for thread-safety problems in old
versions of the STL that were based on the SGI version.
It could also be a problem with the way you're using Xalan classes. I can
see you're using the bridge from the Xerces DOM to Xalan. If that's the
case, you must be _very_ careful if you're trying to share DOM instances
amongst threads. See the documentation for the class XercesParserLiaison
for more details. You'll see there are some accessor functions which
control how the bridge is built, and whether or not it's thread-safe.
If you're not sharing DOM instances between threads, then you can ignore
the previous paragraph, and try the STLport. You could also try a later
version of GCC as the libraries have improved greatly in the 3.x versions.
Dave
"Richard MARSOT"
<Richard_MARSOT@ To: xalan-c-users@xml.apache.org
nmss.com> cc: (bcc: David N Bertoni/Cambridge/IBM)
Subject: STL Multithreading issue under Sparc Solaris (gcc 2.95.3 - Xalan 1.3)
01/07/2003 05:42
AM
Hi,
I am using Xalan C 1.3 under Sparc Solaris with gcc 2.95.3.
In my program, I uses intensively the XalanDOMString class.
It appears that when I use two threads that both uses XalanDOMString
instances, my program core dumps after a while inside the STL library.
If I put mutex between the two threads averything just went fine.
I am struggling to understand if:
1/ this is a known issue in Xalan 1.3 that could have been corrected in 1.4
2/ or is it a known STL issue (not multithread safe under Solaris)
Should I use STLPORT to solve this issue ? If you can give me some advices
to fix this issue, I would really appreciate it.
Thanks a lot for your help.
Richard Marsot.
see below the core dump output
#0 0xfe8339b0 in less<NodeImpl *>::operator() (this=0x1536e4, __x
=@0xffbee358, __y=@0x730074)
at
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3
/../../../../include/g++-3/stl_function.h:111
111 bool operator()(const _Tp& __x, const _Tp& __y) const { return
__x < __y; }
(gdb) bt
#0 0xfe8339b0 in less<NodeImpl *>::operator() (this=0x1536e4, __x
=@0xffbee358, __y=@0x730074)
at
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3
/../../../../include/g++-3/stl_function.h:111
#1 0xfe8467ec in _Rb_tree<NodeImpl *, pair<NodeImpl *const, XalanNode *>,
_Select1st<pair<NodeImpl *const, XalanNode *> >, less<NodeImpl *>,
allocator<XalanNode *> >::insert_unique (this=0x1536dc, __v=@0xffbee358)
at
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3
/../../../../include/g++-3/stl_tree.h:884
#2 0xfe846d1c in map<NodeImpl *, XalanNode *, less<NodeImpl *>,
allocator<XalanNode *> >::insert (this=0x1536dc, __x=@0xffbee358)
at
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3
/../../../../include/g++-3/stl_map.h:162
#3 0xfe437a34 in XercesToXalanNodeMap::addAssociation (this=0x1536d0,
theXercesNode=@0xffbee4f0, theXalanNode=0x8d780)
at XercesParserLiaison/XercesToXalanNodeMap.cpp:97
#4 0xfe42488c in XercesDocumentBridge::createBridgeNode (this=0x1536c0,
theXercesNode=@0xffbee4f0, theIndex=0, mapNode=true)
at XercesParserLiaison/XercesDocumentBridge.cpp:408
#5 0xfe425560 in XercesDocumentBridge::createBridgeNode (this=0x1536c0,
theXercesNode=@0xffbee4f0, theIndex=0, mapNode=true)
at XercesParserLiaison/XercesDocumentBridge.cpp:807
#6 0xfe423b98 in XercesDocumentBridge::mapNode (this=0x1536c0,
theXercesNodeImpl=0x77f80)
at XercesParserLiaison/XercesDocumentBridge.cpp:187
#7 0xfe424240 in XercesDocumentBridge::mapNode (this=0x1536c0,
theXercesNode=@0xffbee5e0)
at XercesParserLiaison/XercesDocumentBridge.cpp:271
#8 0xfe428d10 in XercesDocumentBridge::getDocumentElement (this=0x1536c0)
at XercesParserLiaison/XercesDocumentBridge.cpp:1442
#9 0xff2f50e4 in omuSetProperty (doc={<DOM_Node> = { fImpl =
0x50928}, <No data fields>},
szQuery=0x236d8 "/Properties/Propagation/NumActiveAlarms",
szValue=0xffbee7d0 "1") at omu.cpp:2453
#10 0x19054 in omwSetProperty () at omu_unittest.cpp:195
#11 0x17e04 in main (argc=1, argv=0xffbee9dc) at omu_unittest.cpp:91