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 anirbb <an...@wipro.com> on 2009/03/23 17:29:40 UTC
Issue with xalanc on Solaris when using stlport library
Hi,
We are trying to use xalanc build with stlport library. We are having an
issue --- for some of our xslt, the xalanc binary is hanging. If we do
pstack, the following is the output:
00014e08 void xalanc_1_10::XalanVector<unsigned
short,xalanc_1_10::MemoryManagedConstructionTraits<unsigned short>
>::destroy(unsigned short*,unsigned short*) (5e0e8, ffbff044, 5db04,
fff44ae8, 9, feffceb4) + 30
fef48508
xalanc_1_10::AVT*xalanc_1_10::XalanAVTAllocator::create(xalanc_1_10::StylesheetConstructionContext&,const
xercesc_2_8::Locator*,const unsigned short*,const unsigned short*,const
xalanc_1_10::PrefixResolver&) (ffbff134, ffbff044, 5db04, 57c88, 2084f8,
5da74) + 38
feea1a0c xalanc_1_10::ElemElement::ElemElement #Nvariant
1(xalanc_1_10::StylesheetConstructionContext&,xalanc_1_10::Stylesheet&,const
xercesc_2_8::AttributeList&,int,int) (5da74, ffbff044, 4, 4cba4, 2a5a8, 0) +
150
fef4c7f4
xalanc_1_10::ElemElement*xalanc_1_10::XalanElemElementAllocator::create(xalanc_1_10::StylesheetConstructionContext&,xalanc_1_10::Stylesheet&,const
xercesc_2_8::AttributeList&,int,int) (ffbff204, ffbff044, 3dde8, 4cba4, 4a,
48) + 38
fef1c264 void xalanc_1_10::StylesheetHandler::startElement(const unsigned
short*const,xercesc_2_8::AttributeList&) (ffbfedbc, 34f728, 4cba4, ff01c68c,
feef6a00, ffbfee80) + 6a0
fe622008 void xercesc_2_8::SAXParser::startElement(const
xercesc_2_8::XMLElementDecl&,const unsigned,const unsigned short*const,const
xercesc_2_8::RefVectorOf<xercesc_2_8::XMLAttr>&,const unsigned,const
bool,const bool) (4cb78, 3421a0, 1, 0, 45cc0, 1) + ac
fe5de334 bool xercesc_2_8::IGXMLScanner::scanStartTag(bool&) (4dc80,
fe7e3380, 0, 3421a0, 1, 7) + c90
fe5dbfc4 bool xercesc_2_8::IGXMLScanner::scanContent() (4dc80, 549a8, e7,
3c, 1, ffbfe408) + 120
fe5dab08 void xercesc_2_8::IGXMLScanner::scanDocument(const
xercesc_2_8::InputSource&) (4dc80, ffbfe650, 2c800, fe622d54, 1, 0) + b4
fe6213d0 void xercesc_2_8::SAXParser::parse(const
xercesc_2_8::InputSource&) (fe7aab50, ffbfe650, 64fbc, fe7e313c, 64c00, 0) +
64
fee5fa04 void xalanc_1_10::XercesParserLiaison::parseXMLStream(const
xercesc_2_8::InputSource&,xercesc_2_8::DocumentHandler&,const
xalanc_1_10::XalanDOMString&) (3c490, ffbfe650, ffbfedbc, ff01d024,
fe6216ec, fe7e3298) + 64
fef3bfac
xalanc_1_10::XalanDocument*xalanc_1_10::XSLTEngineImpl::parseXML(const
xercesc_2_8::InputSource&,xercesc_2_8::DocumentHandler*,xalanc_1_10::XalanDocument*)
(0, ffbfe650, ffbfedbc, 0, fefedbec, 800) + 44
fef3be10
xalanc_1_10::XalanDocument*xalanc_1_10::XSLTEngineImpl::parseXML(const
xalanc_1_10::XalanDOMString&,xercesc_2_8::DocumentHandler*,xalanc_1_10::XalanDocument*)
(ffbff330, 3dacc, ffbfedbc, 0, 0, 4cc20) + a0
fef1fb8c void xalanc_1_10::StylesheetHandler::processInclude(const unsigned
short*,const xercesc_2_8::AttributeList&,const xercesc_2_8::Locator*)
(ffbfedbc, fe7e0784, 3f584, 3dacc, 3dab8, 27ef0) + 3ac
fef1c20c void xalanc_1_10::StylesheetHandler::startElement(const unsigned
short*const,xercesc_2_8::AttributeList&) (ffbfedbc, 4ca78, 3f584, feef8e10,
3de24, ffbfee80) + 648
fe62216c void xercesc_2_8::SAXParser::startElement(const
xercesc_2_8::XMLElementDecl&,const unsigned,const unsigned short*const,const
xercesc_2_8::RefVectorOf<xercesc_2_8::XMLAttr>&,const unsigned,const
bool,const bool) (3f558, 4ca08, 1, 0, 3b520, 1) + 210
fe5de334 bool xercesc_2_8::IGXMLScanner::scanStartTag(bool&) (40328,
fe7e3380, 0, 4ca08, 1, 44178) + c90
fe5dbfc4 bool xercesc_2_8::IGXMLScanner::scanContent() (40328, 48070, e7,
3c, 1, ffbfebe8) + 120
fe5dab08 void xercesc_2_8::IGXMLScanner::scanDocument(const
xercesc_2_8::InputSource&) (40328, ffbff8d0, 2c800, fe622d54, 1, 0) + b4
fe6213d0 void xercesc_2_8::SAXParser::parse(const
xercesc_2_8::InputSource&) (fe7aab50, ffbff8d0, 64fbc, fe7e313c, 64c00, 0) +
64
fee5fa04 void xalanc_1_10::XercesParserLiaison::parseXMLStream(const
xercesc_2_8::InputSource&,xercesc_2_8::DocumentHandler&,const
xalanc_1_10::XalanDOMString&) (3c490, ffbff8d0, ffbfedbc, ff01d024,
fe6216ec, fe7e3298) + 64
fef3bb68
xalanc_1_10::StylesheetRoot*xalanc_1_10::XSLTEngineImpl::processStylesheet(const
xalanc_1_10::XSLTInputSource&,xalanc_1_10::StylesheetConstructionContext&)
(ffbff330, ffbff8d0, ffbff044, 3dde8, ffbfedbc, fefedbec) + 1e4
fef3b2cc void xalanc_1_10::XSLTEngineImpl::process(const
xalanc_1_10::XSLTInputSource&,const
xalanc_1_10::XSLTInputSource&,xalanc_1_10::XSLTResultTarget&,xalanc_1_10::StylesheetConstructionContext&,xalanc_1_10::StylesheetExecutionContext&)
(ffbff330, 2ebf0, ffbff8d0, ffbff29c, ffbff044, 2dcb0) + c0
fef5fa78 int xalanc_1_10::XalanTransformer::doTransform(const
xalanc_1_10::XalanParsedSource&,const
xalanc_1_10::XalanCompiledStylesheet*,const
xalanc_1_10::XSLTInputSource*,const xalanc_1_10::XSLTResultTarget&)
(ffbff990, 80, 0, ffbff330, ffbff53c, 200) + 3d4
fef5d1b0 int xalanc_1_10::XalanTransformer::transform(const
xalanc_1_10::XSLTInputSource&,const xalanc_1_10::XSLTInputSource&,const
xalanc_1_10::XSLTResultTarget&) (ffbff990, ffbff910, ffbff8d0, ffbff838,
ffbff838, 0) + 3c
00013f44 int transform(xalanc_1_10::XalanTransformer&,const Params&,const
xalanc_1_10::XSLTInputSource&,const xalanc_1_10::XSLTInputSource&)
(ffbff990, ffbffa50, ffbff910, ffbff8d0, ffbff838, 260f4) + 240
00013abc int xsltMain(int,char**) (3, ffbffadc, 260f4, 26400, ff084740, 0)
+ 248
--
View this message in context: http://www.nabble.com/Issue-with-xalanc-on-Solaris-when-using-stlport-library-tp22663825p22663825.html
Sent from the Xalan - C - Users mailing list archive at Nabble.com.
Re: Issue with xalanc on Solaris when using stlport library
Posted by anirbb <an...@wipro.com>.
Hi Dave,
We used CC/cc compiler version 5.9 and stlport4. In the configure option
we gave -library=stlport4. This enables linking with stlport instead of
libCstd.
With the compiler supplied library (which is by default libCstd) things
work fine. This issue happens only when linked to stlport which is also a
Sun supplied library.
My question is do you think the initialization is necessary?
Regards
Anirban
--
View this message in context: http://www.nabble.com/Issue-with-xalanc-on-Solaris-when-using-stlport-library-tp22663825p22705607.html
Sent from the Xalan - C - Users mailing list archive at Nabble.com.
Re: Issue with xalanc on Solaris when using stlport library
Posted by David Bertoni <db...@apache.org>.
anirbb wrote:
> Hi,
> We are trying to use xalanc build with stlport library. We are having an
> issue --- for some of our xslt, the xalanc binary is hanging. If we do
> pstack, the following is the output:
I don't see any STLport code in the stack. Can you please build with
debug and try this again? Also, please make sure you build a version of
Xalan-C that uses the compiler-supplied standard library to make sure
it's not a compiler problem, or a problem with your usage.
It would also be helpful if you provided the exact version of the Sun
compiler you're using, the exact version of the STLport library, and any
extra command line options you've added to get the compiler to use
STLport instead of the compiler's own standard library.
Note that Xalan-C does not use any of the containers from the standard
library. It does, however, use basic iterator types and the iostreams.
Dave
Re: Issue with xalanc on Solaris when using stlport library
Posted by David Bertoni <db...@apache.org>.
anirbb wrote:
> Hi David,
> We identified the issue is with the following piece of code in
> XalanVector.hpp file. The problem was that the variable theDistance which
> was getting filled up by distance call was containing garbage and for which
> Xalan was trying to allocate some very large memory and was running out of
> memory and crashing.
>
> However we faced this issue only in Solaris with CC compiler and when
> linked to stlport. It works fine with libCstd.
>
> So we have initialized theDistance to 0 and after that things worked fine.
>
> 2 Questions we have:
>
> 1. Under what condition do we need to define XALAN_HAS_STD_DISTANCE?
Sigh. It's very difficult to maintain compatibility with a wide variety
of compilers and library combinations. We really need to update the
build system to use autoconf, so we can avoid a lot of these issues.
>
> 2. Is our change ok (initialization of theDistance)?
This should be unnecessary, since the distance function should assign
the value 0 to the variable. You might just try defining the macro
XALAN_HAS_STD_DISTANCE in SolarisDefinitions.h, to see if that solves
the problem.
Dave
Re: Issue with xalanc on Solaris when using stlport library
Posted by anirbb <an...@wipro.com>.
Hi David,
We identified the issue is with the following piece of code in
XalanVector.hpp file. The problem was that the variable theDistance which
was getting filled up by distance call was containing garbage and for which
Xalan was trying to allocate some very large memory and was running out of
memory and crashing.
However we faced this issue only in Solaris with CC compiler and when
linked to stlport. It works fine with libCstd.
So we have initialized theDistance to 0 and after that things worked fine.
2 Questions we have:
1. Under what condition do we need to define XALAN_HAS_STD_DISTANCE?
2. Is our change ok (initialization of theDistance)?
size_type
local_distance(
const_iterator theFirst,
const_iterator theLast)
{
// Since we're using bare pointers for now, we can
// assert this...
assert(theFirst <= theLast);
#if defined(XALAN_HAS_STD_DISTANCE)
return XALAN_STD_QUALIFIER distance(theFirst, theLast);
#else
size_type theDistance;
XALAN_STD_QUALIFIER distance(theFirst, theLast, theDistance);
return theDistance;
#endif
}
Regards
Anirban
--
View this message in context: http://www.nabble.com/Issue-with-xalanc-on-Solaris-when-using-stlport-library-tp22663825p22704736.html
Sent from the Xalan - C - Users mailing list archive at Nabble.com.