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 David N Bertoni/Cambridge/IBM <da...@us.ibm.com> on 2002/12/02 23:14:09 UTC
Re: Xalan-1.4 crash
You might want to try latest source from CVS, or get the interim release:
http://xml.apache.org/dist/xalan-c/interim-2002-10-21/
If the problem persists, try to reproduce it with a minimal stylesheet,
input document, and code sample a file a bug report.
Dave
Alexei Dets
<ad...@idsk.com> To: xalan-c-users@xml.apache.org
cc: (bcc: David N Bertoni/Cambridge/IBM)
11/29/2002 01:31 Subject: Xalan-1.4 crash
PM
Hi!
I have a Linux RedHat-7.3 box with self-compiled (with gcc-3.2)
Xerces-2.1.0 &
Xalan-1.4.
I had a set of classes that were doing XSL transformations for my previous
project, this project was using Xerces-1.7.0 + CVS version of Xalan 1.4 (~
a
month or two before release). And I was using gcc-2.96 from RedHat.
Now I just moved the same classes (custom EntityResolver and ErrorHandler +
class that calls XalanTransformer) to the new project, compiled it with the
new libraries and... I have _complitely_ corrupted results. Just some mess
instead of transformation result :-(
If I'm linking with debug version of Xalan I'm getting the crash:
(gdb) bt
#0 0x42028cc1 in kill () from /lib/i686/libc.so.6
#1 0x4081c07d in raise () from /lib/i686/libpthread.so.0
#2 0x4202a019 in abort () from /lib/i686/libc.so.6
#3 0x42021cd6 in __assert_fail () from /lib/i686/libc.so.6
#4 0x4028d6de in ~XalanReferenceCountedObject (this=0x80d849c) at
PlatformSupport/XalanReferenceCountedObject.cpp:80
#5 0x402e0294 in ~XObject (this=0x80d849c) at XPath/XObject.cpp:102
#6 0x402df898 in ~XNumberBase (this=0x80d849c) at XPath/XNumberBase.cpp:86
#7 0x40324a5a in ~XTokenNumberAdapter (this=0x80d849c) at
XPath/XTokenNumberAdapter.cpp:84
#8 0x40322ffa in
ArenaBlockDestroy<XTokenNumberAdapter>::operator()(XTokenNumberAdapter&)
const (this=0x809525c, theObject=@0x80d849c)
at PlatformSupport/ArenaBlock.hpp:134
#9 0x403237e2 in
ArenaBlock<XTokenNumberAdapter>::DeleteFunctor::operator()(XTokenNumberAdapter&)
const (this=0x40b1fdb4,
theObject=@0x80d849c) at PlatformSupport/ArenaBlock.hpp:412
#10 0x403235ea in ArenaBlock<XTokenNumberAdapter>::DeleteFunctor
std::for_each<XTokenNumberAdapter*,
ArenaBlock<XTokenNumberAdapter>::DeleteFunctor>(XTokenNumberAdapter*,
XTokenNumberAdapter*, ArenaBlock<XTokenNumberAdapter>::DeleteFunctor)
(__first=0x80d849c,
__last=0x80d84b0, __f={m_arenaBlock = @0x8095258, m_destroyFunction =
@0x809525c}) at /usr/include/c++/3.2/bits/stl_algo.h:157
#11 0x4032330a in ArenaBlock<XTokenNumberAdapter>::destroyAll()
(this=0x8095258) at PlatformSupport/ArenaBlock.hpp:340
#12 0x4032417e in ~ReusableArenaBlock (this=0x8095258) at
PlatformSupport/ReusableArenaBlock.hpp:94
#13 0x403234d2 in
ArenaDeleteFunctor<ReusableArenaBlock<XTokenNumberAdapter>
>::operator()(ReusableArenaBlock<XTokenNumberAdapter> const*) const
(this=0x40b1fe78, theType=0x8095258) at
PlatformSupport/ArenaAllocator.hpp:83
#14 0x40323094 in
ArenaDeleteFunctor<ReusableArenaBlock<XTokenNumberAdapter> >
std::for_each<__gnu_cxx::__normal_iterator<ReusableArenaBlock<XTokenNumberAdapter>**,
std::vector<ReusableArenaBlock<XTokenNumberAdapter>*,
std::allocator<ReusableArenaBlock<XTokenNumberAdapter>*> > >,
ArenaDeleteFunctor<ReusableArenaBlock<XTokenNumberAdapter> >
>(__gnu_cxx::__normal_iterator<ReusableArenaBlock<XTokenNumberAdapter>**,
std::vector<ReusableArenaBlock<XTokenNumberAdapter>*,
std::allocator<ReusableArenaBlock<XTokenNumberAdapter>*> > >,
__gnu_cxx::__normal_iterator<ReusableArenaBlock<XTokenNumberAdapter>**,
std::vector<ReusableArenaBlock<XTokenNumberAdapter>*,
std::allocator<ReusableArenaBlock<XTokenNumberAdapter>*> > >,
ArenaDeleteFunctor<ReusableArenaBlock<XTokenNumberAdapter> >) (__first=
{<iterator<std::random_access_iterator_tag,ReusableArenaBlock<XTokenNumberAdapter>*,int,ReusableArenaBlock<XTokenNumberAdapter>**,ReusableArenaBlock<XTokenNumberAdapter>*&>>
= {<No data fields>}, _M_current = 0x813ac28}, __last=
{<iterator<std::random_access_iterator_tag,ReusableArenaBlock<XTokenNumberAdapter>*,int,ReusableArenaBlock<XTokenNumberAdapter>**,ReusableArenaBlock<XTokenNumberAdapter>*&>>
= {<No data fields>}, _M_current = 0x813ac2c}, __f={<No data fields>})
at /usr/include/c++/3.2/bits/stl_algo.h:157
#15 0x40322954 in ArenaAllocator<XTokenNumberAdapter,
ReusableArenaBlock<XTokenNumberAdapter> >::reset() (this=0x40b20220)
at PlatformSupport/ArenaAllocator.hpp:227
#16 0x40322520 in ~ArenaAllocator (this=0x40b20220) at
PlatformSupport/ArenaAllocator.hpp:116
#17 0x40321fec in ~ReusableArenaAllocator (this=0x40b20220) at
PlatformSupport/ReusableArenaAllocator.hpp:106
#18 0x40321da4 in ~XTokenNumberAdapterAllocator (this=0x40b20220) at
XPath/XTokenNumberAdapterAllocator.cpp:72
#19 0x402e5c3c in ~XObjectFactoryDefault (this=0x40b2018c) at
XPath/XObjectFactoryDefault.cpp:107
#20 0x40410b1a in XalanTransformer::doTransform(XalanParsedSource const&,
XalanCompiledStylesheet const*, XSLTInputSource const*, XSLTResultTarget
const&) (this=0x40b20930, theParsedXML=@0x80ca9c8,
theCompiledStylesheet=0x80933e0, theStylesheetSource=0x0,
theResultTarget=@0x40b203ec) at
XalanTransformer/XalanTransformer.cpp:1181
#21 0x0804fde1 in XalanTransformer::transform(XalanParsedSource const&,
XalanCompiledStylesheet const*, XSLTResultTarget const&) (
this=0x40b20930, theParsedXML=@0x80ca9c8,
theCompiledStylesheet=0x80933e0,
theResultTarget=@0x40b203ec)
at
../ThirdParty/Linux/xalan/include/XalanTransformer/XalanTransformer.hpp:196
#22 0x0804f58a in TXMLProcessor::process(TXMLDocument&) (this=0x40b2091c,
xml=@0x40b2070c) at txmlprocessor.cpp:111
#23 0x0805188a in receiverThread(void*) (dataSource=0x805c5f0) at
main.cpp:197
#24 0x40819941 in pthread_start_thread () from /lib/i686/libpthread.so.0
Can anybody give me some idea? :-( It was a working code :-(
Alexei
Re: Xalan-1.4 crash
Posted by David N Bertoni/Cambridge/IBM <da...@us.ibm.com>.
Hi Alexei,
Xalan "never" writes a null byte to the end of the stream, as it has no
idea that you're writing to a "string". This behavior has been consistent
since the first version of Xalan was released.
If this worked before it was just by chance, or was, as you suggested,
attributable to a particular library's behavior.
Dave
Alexei Dets
<ad...@idsk.com> To: <xa...@xml.apache.org>
cc: (bcc: David N Bertoni/Cambridge/IBM)
12/03/2002 03:09 Subject: Re: Xalan-1.4 crash
PM
Hi!
Seems that I've found the reason of the problem and it looks like a bug in
my
own code ;-)))
The bad thing is that this code compiles and works without any problems
with
the previous versions of Xalan, gcc-2.96 or Sun Workshop 6.0.
Probably the bug was triggered by update to gcc-3.2 or Xalan-1.4.
Here is the code example:
....
std::ostringstream resultStream;
XSLTResultTarget result(resultStream);
transformer.transform(*parsedXML, bodyXSL, result);
bodyStr = resultStream.str().c_str();
resultStream.seekp(0);
transformer.transform(*parsedXML, dateXSL, result);
dateStr = resultStream.str().c_str();
....
Seems that in the old setup calling "resultStream.seekp(0);" was cleaning
the
stream and setting write position to zero (or Xalan was writing '\0' to the
stream at the end of the transformation result), not it is only setting
position. So, in my case, result of the first transformation will be
correct,
of the second (and all subsequent) will contain trailing garbage from the
first transformation.
To achieve the same behaviour as before I've changed:
resultStream.seekp(0);
to:
resultStream.seekp(0);
resultStream.str("");
In this case it works as expected.
Alexei
Re: Xalan-1.4 crash
Posted by Alexei Dets <ad...@idsk.com>.
Hi!
Seems that I've found the reason of the problem and it looks like a bug in my
own code ;-)))
The bad thing is that this code compiles and works without any problems with
the previous versions of Xalan, gcc-2.96 or Sun Workshop 6.0.
Probably the bug was triggered by update to gcc-3.2 or Xalan-1.4.
Here is the code example:
....
std::ostringstream resultStream;
XSLTResultTarget result(resultStream);
transformer.transform(*parsedXML, bodyXSL, result);
bodyStr = resultStream.str().c_str();
resultStream.seekp(0);
transformer.transform(*parsedXML, dateXSL, result);
dateStr = resultStream.str().c_str();
....
Seems that in the old setup calling "resultStream.seekp(0);" was cleaning the
stream and setting write position to zero (or Xalan was writing '\0' to the
stream at the end of the transformation result), not it is only setting
position. So, in my case, result of the first transformation will be correct,
of the second (and all subsequent) will contain trailing garbage from the
first transformation.
To achieve the same behaviour as before I've changed:
resultStream.seekp(0);
to:
resultStream.seekp(0);
resultStream.str("");
In this case it works as expected.
Alexei