You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-users@xerces.apache.org by rl...@codelibre.net on 2016/01/21 16:27:09 UTC
Strange interaction between Xerces and Xalan
Hi folks,
I've run into an odd situation which I hope someone might be able to
shed some light upon.
I have a library using Xerces-C. This works on multiple platforms, and
works fine. Yesterday, I added initial support for Xalan-C. This
appears to work on all platforms, except for one (FreeBSD with xerces-c3
and xalan-c from ports). Both are compiled without ICU support.
$ ldd /usr/local/lib/libxerces-c.so
/usr/local/lib/libxerces-c.so:
libthr.so.3 => /lib/libthr.so.3 (0x8019c0000)
libc++.so.1 => /usr/lib/libc++.so.1 (0x801be4000)
libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x801ea3000)
libm.so.5 => /lib/libm.so.5 (0x8020bf000)
libc.so.7 => /lib/libc.so.7 (0x800821000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x8022e8000)
$ ldd /usr/local/lib/libxalan-c.so
/usr/local/lib/libxalan-c.so:
libm.so.5 => /lib/libm.so.5 (0x801b15000)
libxerces-c-3.1.so => /usr/local/lib/libxerces-c-3.1.so
(0x801e00000)
libxalanMsg.so => /usr/local/lib/libxalanMsg.so (0x8023c0000)
libc++.so.1 => /usr/lib/libc++.so.1 (0x8025c8000)
libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x802887000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x802aa3000)
libc.so.7 => /lib/libc.so.7 (0x800821000)
libthr.so.3 => /lib/libthr.so.3 (0x802cb1000)
My unit test here fails with "invalid document structure". However, the
XML is well-formed UTF-8 with no BOM; it's been working fine for years.
The difference between the exception being thrown or not thrown is very
simple: whether or not I link Xerces-C (works) or Xerces-C *and* Xalan-C
(fails). I'm not *using* Xalan-C, I'm merely linking my shared library
against it.
What I don't understand is why xercesc::AbstractDOMParser::parse would
be affected by linking Xalan-C into my library. Does it have some
dynamically-registered hooks which subtly alter the behaviour of
Xerces-C? There's no visible presence of Xalan in the stacktrace below,
but it's clearly had *some* effect. If I remove Xalan from the linker
options, it works immediately.
Another data point: If I build Xerces-C from source on the same
platform, linking against ICU, it works with Xalan-C built from source
(without ICU). Is there some required combination to get a functional
setup? The other platforms also had Xerces compiled against ICU. Or
any way to configure things to make it work?
Kind regards,
Roger
(gdb) run
Starting program: /tmp/ome-common-cpp/b/test/ome-common/xerces
[==========] Running 80 tests from 1 test case.
[----------] Global test environment set-up.
[----------] 80 tests from XercesVariants/XercesTest
[ RUN ] XercesVariants/XercesTest.Node/0
[ OK ] XercesVariants/XercesTest.Node/0 (7 ms)
[ RUN ] XercesVariants/XercesTest.Node/1
Fatal Error at file "streambuf", line 1, column 1
Message: invalid document structure
[New Thread 807406400 (LWP 101339)]
[Switching to Thread 807406400 (LWP 101339)]
Catchpoint 1 (exception thrown), 0x000000080390c3c4 in __cxa_throw ()
from /lib/libcxxrt.so.1
(gdb) bt
#0 0x000000080390c3c4 in __cxa_throw () from /lib/libcxxrt.so.1
#1 0x0000000802ddfaf7 in
xercesc_3_1::XMLScanner::emitError(xercesc_3_1::XMLErrs::Codes) () from
/usr/local/lib/libxerces-c-3.1.so
#2 0x0000000802ddf81d in xercesc_3_1::XMLScanner::scanProlog() () from
/usr/local/lib/libxerces-c-3.1.so
#3 0x0000000802db62dd in
xercesc_3_1::IGXMLScanner::scanDocument(xercesc_3_1::InputSource const&)
() from /usr/local/lib/libxerces-c-3.1.so
#4 0x0000000802dfc834 in
xercesc_3_1::AbstractDOMParser::parse(xercesc_3_1::InputSource const&)
() from /usr/local/lib/libxerces-c-3.1.so
#5 0x00000008008ff37c in (anonymous
namespace)::read_source(xercesc_3_1::XercesDOMParser&,
ome::common::xml::EntityResolver&, xercesc_3_1::InputSource&) () from
/tmp/ome-common-cpp/b/lib/ome/common/libome-common.so.5.2.0
#6 0x00000008008ffea0 in
ome::common::xml::dom::createDocument(std::__1::basic_istream<char,
std::__1::char_traits<char> >&, ome::common::xml::EntityResolver&,
ome::common::xml::dom::ParseParameters const&,
std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> > const&) () from
/tmp/ome-common-cpp/b/lib/ome/common/libome-common.so.5.2.0
#7 0x00000008008dc48b in
ome::common::xml::EntityResolver::registerCatalog(boost::filesystem::path
const&) ()
from /tmp/ome-common-cpp/b/lib/ome/common/libome-common.so.5.2.0
#8 0x00000000004278dd in XercesTest::SetUp() ()
#9 0x00000008031f9ad4 in void
testing::internal::HandleExceptionsInMethodIfSupported<testing::Test,
void>(testing::Test*, void (testing::Test::*)(), char const*) () from
/usr/local/lib/libgtest.so.0
#10 0x00000008031e330b in testing::Test::Run() () from
/usr/local/lib/libgtest.so.0
#11 0x00000008031e43c4 in testing::TestInfo::Run() () from
/usr/local/lib/libgtest.so.0
#12 0x00000008031e4c20 in testing::TestCase::Run() () from
/usr/local/lib/libgtest.so.0
#13 0x00000008031ec467 in testing::internal::UnitTestImpl::RunAllTests()
() from /usr/local/lib/libgtest.so.0
#14 0x00000008031fa784 in bool
testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl,
bool>(testing::internal::UnitTestImpl*, bool
(testing::internal::UnitTestImpl::*)(), char const*) () from
/usr/local/lib/libgtest.so.0
#15 0x00000008031ec0f6 in testing::UnitTest::Run() () from
/usr/local/lib/libgtest.so.0
#16 0x0000000000444641 in RUN_ALL_TESTS() ()
#17 0x0000000000444485 in main ()
Re: Strange interaction between Xerces and Xalan
Posted by Roger Leigh <rl...@codelibre.net>.
On 21/01/2016 16:17, rleigh@codelibre.net wrote:
> On 2016-01-21 15:27, rleigh@codelibre.net wrote:
>
>> My unit test here fails with "invalid document structure". However,
>> the XML is well-formed UTF-8 with no BOM; it's been working fine for
>> years.
>>
>> The difference between the exception being thrown or not thrown is
>> very simple: whether or not I link Xerces-C (works) or Xerces-C *and*
>> Xalan-C (fails). I'm not *using* Xalan-C, I'm merely linking my
>> shared library against it.
It looks like this is now fixed by
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206472
and appears to have been a lack of iconv support in xerces-c.
I've now subsequently hit an odd failed assertion in xalan-c, which is
likely not of interest to the xerces-c readers. The assertion is in
XalanReferenceCountedObject, where it's failing an assert in the
destructor. Are there any known circumstances where this can be
triggered, e.g. particular build configurations? I don't think it's
platform-specific, since it's working for me on FreeBSD with an
ICU-enabled xerces-c and an ICU-disabled xalan-c. This is with ICU
disabled for both using the ports builds of each. The test is passing
on Linux, MacOS X and Windows, so I don't think my code is faulty either.
Any suggestions greatly appreciated.
Thanks,
Roger
gdb test/ome-common/xalan
[...]
(gdb) run
[...]
[==========] Running 91 tests from 10 test cases.
[----------] Global test environment set-up.
[----------] 1 test from XalanSkipTest
[ RUN ] XalanSkipTest.PlatformRefCountSkipInit
[ OK ] XalanSkipTest.PlatformRefCountSkipInit (14 ms)
[----------] 1 test from XalanSkipTest (15 ms total)
[----------] 10 tests from XalanTransformTypes/XalanTest/0, where
TypeParam = TestTypes<boost::filesystem::path, boost::filesystem::path>
[ RUN ] XalanTransformTypes/XalanTest/0.Platform
[ OK ] XalanTransformTypes/XalanTest/0.Platform (20 ms)
[ RUN ] XalanTransformTypes/XalanTest/0.PlatformRefCount
[ OK ] XalanTransformTypes/XalanTest/0.PlatformRefCount (18 ms)
[ RUN ] XalanTransformTypes/XalanTest/0.TransformConstruct
[ OK ] XalanTransformTypes/XalanTest/0.TransformConstruct (18 ms)
[ RUN ] XalanTransformTypes/XalanTest/0.TransformSetEntityResolver
[ OK ] XalanTransformTypes/XalanTest/0.TransformSetEntityResolver
(16 ms)
[ RUN ] XalanTransformTypes/XalanTest/0.TransformApply
Testing transform of path to path using
"/tmp/ome-common-cpp/test/ome-common/data/18x24y5z5t2c8b-text.ome"and
"/tmp/ome-common-cpp/test/ome-common/data/2012-06-to-2013-06.xsl"
Assertion failed: (theInstance->m_referenceCount < UINT_MAX), function
addReference, file
/usr/ports/textproc/xalan-c/work/xalan-c-1.11/c/src/xalanc/PlatformSupport/XalanReferenceCountedObject.cpp,
line 55.
[New Thread 807806400 (LWP 101332/xalan)]
Program received signal SIGABRT, Aborted.
[Switching to Thread 807806400 (LWP 101332/xalan)]
0x000000080420c64a in thr_kill () from /lib/libc.so.7
(gdb) bt
#0 0x000000080420c64a in thr_kill () from /lib/libc.so.7
#1 0x000000080420c636 in raise () from /lib/libc.so.7
#2 0x000000080420c5b9 in abort () from /lib/libc.so.7
#3 0x0000000804272fd1 in __assert () from /lib/libc.so.7
#4 0x00000008027f7985 in
xalanc_1_11::XalanReferenceCountedObject::addReference () from
/usr/local/lib/libxalan-c.so
#5 0x00000008028fbbd4 in xalanc_1_11::XPath::execute () from
/usr/local/lib/libxalan-c.so
#6 0x00000008028fac90 in
xalanc_1_11::ElemForEach::createSelectedAndSortedNodeList () from
/usr/local/lib/libxalan-c.so
#7 0x000000080298cf72 in
xalanc_1_11::ElemApplyTemplates::getFirstChildElemToExecute () from
/usr/local/lib/libxalan-c.so
#8 0x0000000802947615 in xalanc_1_11::ElemTemplateElement::execute ()
from /usr/local/lib/libxalan-c.so
#9 0x000000080296a7f4 in xalanc_1_11::StylesheetRoot::process () from
/usr/local/lib/libxalan-c.so
#10 0x000000080294b2f8 in xalanc_1_11::XSLTEngineImpl::process () from
/usr/local/lib/libxalan-c.so
#11 0x00000008029f2fe0 in xalanc_1_11::XalanTransformer::doTransform ()
from /usr/local/lib/libxalan-c.so
#12 0x00000008029ef3ac in xalanc_1_11::XalanTransformer::transform ()
from /usr/local/lib/libxalan-c.so
#13 0x0000000800970cbd in ome::common::xsl::Transformer::transform ()
from /tmp/b2/ome-common-build/lib/ome/common/libome-common.so.5.2.0
#14 0x0000000800970dc5 in ome::common::xsl::Transformer::transform ()
from /tmp/b2/ome-common-build/lib/ome/common/libome-common.so.5.2.0
#15 0x000000000044503e in XalanTest<TestTypes<boost::filesystem::path,
boost::filesystem::path> >::TestTransform ()
#16 0x0000000000460a9d in
gtest_case_XalanTest_::TransformApply<TestTypes<boost::filesystem::path,
boost::filesystem::path> >::TestBody ()
#17 0x00000008033faad4 in
testing::internal::HandleExceptionsInMethodIfSupported<testing::Test,
void> () from /usr/local/lib/libgtest.so.0
#18 0x00000008033e4372 in testing::Test::Run () from
/usr/local/lib/libgtest.so.0
#19 0x00000008033e53c4 in testing::TestInfo::Run () from
/usr/local/lib/libgtest.so.0
#20 0x00000008033e5c20 in testing::TestCase::Run () from
/usr/local/lib/libgtest.so.0
#21 0x00000008033ed467 in testing::internal::UnitTestImpl::RunAllTests
() from /usr/local/lib/libgtest.so.0
#22 0x00000008033fb784 in
testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl,
bool> ()
from /usr/local/lib/libgtest.so.0
#23 0x00000008033ed0f6 in testing::UnitTest::Run () from
/usr/local/lib/libgtest.so.0
#24 0x0000000000490fd1 in RUN_ALL_TESTS ()
#25 0x0000000000490e15 in main ()
Re: Strange interaction between Xerces and Xalan
Posted by Roger Leigh <rl...@codelibre.net>.
On 21/01/2016 16:17, rleigh@codelibre.net wrote:
> On 2016-01-21 15:27, rleigh@codelibre.net wrote:
>
>> My unit test here fails with "invalid document structure". However,
>> the XML is well-formed UTF-8 with no BOM; it's been working fine for
>> years.
>>
>> The difference between the exception being thrown or not thrown is
>> very simple: whether or not I link Xerces-C (works) or Xerces-C *and*
>> Xalan-C (fails). I'm not *using* Xalan-C, I'm merely linking my
>> shared library against it.
It looks like this is now fixed by
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206472
and appears to have been a lack of iconv support in xerces-c.
I've now subsequently hit an odd failed assertion in xalan-c, which is
likely not of interest to the xerces-c readers. The assertion is in
XalanReferenceCountedObject, where it's failing an assert in the
destructor. Are there any known circumstances where this can be
triggered, e.g. particular build configurations? I don't think it's
platform-specific, since it's working for me on FreeBSD with an
ICU-enabled xerces-c and an ICU-disabled xalan-c. This is with ICU
disabled for both using the ports builds of each. The test is passing
on Linux, MacOS X and Windows, so I don't think my code is faulty either.
Any suggestions greatly appreciated.
Thanks,
Roger
gdb test/ome-common/xalan
[...]
(gdb) run
[...]
[==========] Running 91 tests from 10 test cases.
[----------] Global test environment set-up.
[----------] 1 test from XalanSkipTest
[ RUN ] XalanSkipTest.PlatformRefCountSkipInit
[ OK ] XalanSkipTest.PlatformRefCountSkipInit (14 ms)
[----------] 1 test from XalanSkipTest (15 ms total)
[----------] 10 tests from XalanTransformTypes/XalanTest/0, where
TypeParam = TestTypes<boost::filesystem::path, boost::filesystem::path>
[ RUN ] XalanTransformTypes/XalanTest/0.Platform
[ OK ] XalanTransformTypes/XalanTest/0.Platform (20 ms)
[ RUN ] XalanTransformTypes/XalanTest/0.PlatformRefCount
[ OK ] XalanTransformTypes/XalanTest/0.PlatformRefCount (18 ms)
[ RUN ] XalanTransformTypes/XalanTest/0.TransformConstruct
[ OK ] XalanTransformTypes/XalanTest/0.TransformConstruct (18 ms)
[ RUN ] XalanTransformTypes/XalanTest/0.TransformSetEntityResolver
[ OK ] XalanTransformTypes/XalanTest/0.TransformSetEntityResolver
(16 ms)
[ RUN ] XalanTransformTypes/XalanTest/0.TransformApply
Testing transform of path to path using
"/tmp/ome-common-cpp/test/ome-common/data/18x24y5z5t2c8b-text.ome"and
"/tmp/ome-common-cpp/test/ome-common/data/2012-06-to-2013-06.xsl"
Assertion failed: (theInstance->m_referenceCount < UINT_MAX), function
addReference, file
/usr/ports/textproc/xalan-c/work/xalan-c-1.11/c/src/xalanc/PlatformSupport/XalanReferenceCountedObject.cpp,
line 55.
[New Thread 807806400 (LWP 101332/xalan)]
Program received signal SIGABRT, Aborted.
[Switching to Thread 807806400 (LWP 101332/xalan)]
0x000000080420c64a in thr_kill () from /lib/libc.so.7
(gdb) bt
#0 0x000000080420c64a in thr_kill () from /lib/libc.so.7
#1 0x000000080420c636 in raise () from /lib/libc.so.7
#2 0x000000080420c5b9 in abort () from /lib/libc.so.7
#3 0x0000000804272fd1 in __assert () from /lib/libc.so.7
#4 0x00000008027f7985 in
xalanc_1_11::XalanReferenceCountedObject::addReference () from
/usr/local/lib/libxalan-c.so
#5 0x00000008028fbbd4 in xalanc_1_11::XPath::execute () from
/usr/local/lib/libxalan-c.so
#6 0x00000008028fac90 in
xalanc_1_11::ElemForEach::createSelectedAndSortedNodeList () from
/usr/local/lib/libxalan-c.so
#7 0x000000080298cf72 in
xalanc_1_11::ElemApplyTemplates::getFirstChildElemToExecute () from
/usr/local/lib/libxalan-c.so
#8 0x0000000802947615 in xalanc_1_11::ElemTemplateElement::execute ()
from /usr/local/lib/libxalan-c.so
#9 0x000000080296a7f4 in xalanc_1_11::StylesheetRoot::process () from
/usr/local/lib/libxalan-c.so
#10 0x000000080294b2f8 in xalanc_1_11::XSLTEngineImpl::process () from
/usr/local/lib/libxalan-c.so
#11 0x00000008029f2fe0 in xalanc_1_11::XalanTransformer::doTransform ()
from /usr/local/lib/libxalan-c.so
#12 0x00000008029ef3ac in xalanc_1_11::XalanTransformer::transform ()
from /usr/local/lib/libxalan-c.so
#13 0x0000000800970cbd in ome::common::xsl::Transformer::transform ()
from /tmp/b2/ome-common-build/lib/ome/common/libome-common.so.5.2.0
#14 0x0000000800970dc5 in ome::common::xsl::Transformer::transform ()
from /tmp/b2/ome-common-build/lib/ome/common/libome-common.so.5.2.0
#15 0x000000000044503e in XalanTest<TestTypes<boost::filesystem::path,
boost::filesystem::path> >::TestTransform ()
#16 0x0000000000460a9d in
gtest_case_XalanTest_::TransformApply<TestTypes<boost::filesystem::path,
boost::filesystem::path> >::TestBody ()
#17 0x00000008033faad4 in
testing::internal::HandleExceptionsInMethodIfSupported<testing::Test,
void> () from /usr/local/lib/libgtest.so.0
#18 0x00000008033e4372 in testing::Test::Run () from
/usr/local/lib/libgtest.so.0
#19 0x00000008033e53c4 in testing::TestInfo::Run () from
/usr/local/lib/libgtest.so.0
#20 0x00000008033e5c20 in testing::TestCase::Run () from
/usr/local/lib/libgtest.so.0
#21 0x00000008033ed467 in testing::internal::UnitTestImpl::RunAllTests
() from /usr/local/lib/libgtest.so.0
#22 0x00000008033fb784 in
testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl,
bool> ()
from /usr/local/lib/libgtest.so.0
#23 0x00000008033ed0f6 in testing::UnitTest::Run () from
/usr/local/lib/libgtest.so.0
#24 0x0000000000490fd1 in RUN_ALL_TESTS ()
#25 0x0000000000490e15 in main ()
Re: Strange interaction between Xerces and Xalan
Posted by rl...@codelibre.net.
On 2016-01-21 15:27, rleigh@codelibre.net wrote:
> My unit test here fails with "invalid document structure". However,
> the XML is well-formed UTF-8 with no BOM; it's been working fine for
> years.
>
> The difference between the exception being thrown or not thrown is
> very simple: whether or not I link Xerces-C (works) or Xerces-C *and*
> Xalan-C (fails). I'm not *using* Xalan-C, I'm merely linking my
> shared library against it.
>
> What I don't understand is why xercesc::AbstractDOMParser::parse would
> be affected by linking Xalan-C into my library. Does it have some
> dynamically-registered hooks which subtly alter the behaviour of
> Xerces-C? There's no visible presence of Xalan in the stacktrace
> below, but it's clearly had *some* effect. If I remove Xalan from the
> linker options, it works immediately.
>
> Another data point: If I build Xerces-C from source on the same
> platform, linking against ICU, it works with Xalan-C built from source
> (without ICU). Is there some required combination to get a functional
> setup? The other platforms also had Xerces compiled against ICU. Or
> any way to configure things to make it work?
An additional observation. I recompiled the xerces-c3 port with the icu
transcoder in place of the iconv transcoder, and then recompiled the
xalan-c port against it. When I rebuild and re-run my code, the tests
then pass. So it can at least be made to work, but there's still a bit
of a mystery in why this is happening.
- why does xalan break xerces when icu support is missing from both,
merely by the act of linking it in?
- why does building xerces (not xalan) with ICU support fix this?
Could it be these:
$ nm -D -C /usr/local/lib/libxalan-c.so|grep " W xercesc_"
0000000000344a90 W
xercesc_3_1::InputSource::setIssueFatalErrorIfNotFound(bool)
00000000003472b0 W xercesc_3_1::ErrorHandler::~ErrorHandler()
0000000000214e40 W xercesc_3_1::SAXException::~SAXException()
0000000000214e10 W xercesc_3_1::SAXException::~SAXException()
00000000001da9b0 W
xercesc_3_1::OutOfMemoryException::~OutOfMemoryException()
0000000000344a50 W xercesc_3_1::InputSource::getEncoding() const
0000000000344a60 W xercesc_3_1::InputSource::getPublicId() const
0000000000344a70 W xercesc_3_1::InputSource::getSystemId() const
0000000000344a80 W
xercesc_3_1::InputSource::getIssueFatalErrorIfNotFound() const
0000000000214e90 W xercesc_3_1::SAXException::getMessage() const
Could xalan be providing replacement InputSource methods which are not
functioning correctly, resulting in invalid input? These are the only
obvious symbols I can see which could override xerces symbols (the rest
are vtables/typinfo).
Regards,
Roger
Re: Strange interaction between Xerces and Xalan
Posted by rl...@codelibre.net.
On 2016-01-21 15:27, rleigh@codelibre.net wrote:
> My unit test here fails with "invalid document structure". However,
> the XML is well-formed UTF-8 with no BOM; it's been working fine for
> years.
>
> The difference between the exception being thrown or not thrown is
> very simple: whether or not I link Xerces-C (works) or Xerces-C *and*
> Xalan-C (fails). I'm not *using* Xalan-C, I'm merely linking my
> shared library against it.
>
> What I don't understand is why xercesc::AbstractDOMParser::parse would
> be affected by linking Xalan-C into my library. Does it have some
> dynamically-registered hooks which subtly alter the behaviour of
> Xerces-C? There's no visible presence of Xalan in the stacktrace
> below, but it's clearly had *some* effect. If I remove Xalan from the
> linker options, it works immediately.
>
> Another data point: If I build Xerces-C from source on the same
> platform, linking against ICU, it works with Xalan-C built from source
> (without ICU). Is there some required combination to get a functional
> setup? The other platforms also had Xerces compiled against ICU. Or
> any way to configure things to make it work?
An additional observation. I recompiled the xerces-c3 port with the icu
transcoder in place of the iconv transcoder, and then recompiled the
xalan-c port against it. When I rebuild and re-run my code, the tests
then pass. So it can at least be made to work, but there's still a bit
of a mystery in why this is happening.
- why does xalan break xerces when icu support is missing from both,
merely by the act of linking it in?
- why does building xerces (not xalan) with ICU support fix this?
Could it be these:
$ nm -D -C /usr/local/lib/libxalan-c.so|grep " W xercesc_"
0000000000344a90 W
xercesc_3_1::InputSource::setIssueFatalErrorIfNotFound(bool)
00000000003472b0 W xercesc_3_1::ErrorHandler::~ErrorHandler()
0000000000214e40 W xercesc_3_1::SAXException::~SAXException()
0000000000214e10 W xercesc_3_1::SAXException::~SAXException()
00000000001da9b0 W
xercesc_3_1::OutOfMemoryException::~OutOfMemoryException()
0000000000344a50 W xercesc_3_1::InputSource::getEncoding() const
0000000000344a60 W xercesc_3_1::InputSource::getPublicId() const
0000000000344a70 W xercesc_3_1::InputSource::getSystemId() const
0000000000344a80 W
xercesc_3_1::InputSource::getIssueFatalErrorIfNotFound() const
0000000000214e90 W xercesc_3_1::SAXException::getMessage() const
Could xalan be providing replacement InputSource methods which are not
functioning correctly, resulting in invalid input? These are the only
obvious symbols I can see which could override xerces symbols (the rest
are vtables/typinfo).
Regards,
Roger