You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by Lonnie VanZandt <lo...@ngc.com> on 2005/06/16 14:12:38 UTC
XPathEvaluator sigsegv's on NodeRefList::operator=
Using some code very similar to the samples/SerializeNodeSet example, I
currently get a core dump which shows that NodeRefList::operator= tried to
dereference a null. (This is Xalan C++ 1.9).
The preceding call to selectSingleNode returned a non-null contextNode for a
non-null XalanDocument but the selectNodeList call which is given that
contextNode and an empty (getLength=0) NodeRefList dumps core.
I gather that the internal evaluate call is returning an XObjectPtr whose
member pointer is 0. Then when operator= tries to copy theResult->nodeset()
into the NodeRefList& which I pass in, the null derefence "fires".
Now, it may be that there is a scoping or a memory manager issue which I've
overlooked while reading the Xalan C++ API, sample code, and mailing lists.
My XPathEvaluator, the NodeRefList, the source XalanDocument, and the context
node all have greater, outer scope when selectNodeList gets called. Also, I
can dereference the passed in NodeRefList& (via myNodeRefList.getLength())
safely immediately before the selectNodeList call within the same scope.
Has this (likely pilot) error been encountered before?
Perhaps my XalanDocument, constructed via the parserLiaison parseXMLStream
method is somehow malformed? (The original source XML is assuredly
well-formed because a peer XalanTransformer has no problems translating it
from its original XSLTInputSource...)
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: XPathEvaluator sigsegv's on NodeRefList::operator=
Posted by Lonnie VanZandt <lo...@ngc.com>.
And, just to reveal all of my puzzle: the source const char * const xml array
contains known-to-be-valid, well-formed XML which begins
"<casperAPI><trigger>..." and so that first XPath query should return a match
at <trigger>.
On Thursday 16 June 2005 08:17 am, Lonnie VanZandt wrote:
> Oh, there's an intervening method which resolves the context node from a
> XalanDOMString expression. That is:
>
> //! evaluate an XPath expression for a given XalanDOM and a given
> starting context
> void evaluateQuery( XalanDocument * const pXalanDoc,
> XalanDOMString xdsContext,
> XalanDOMString xdsPathExpr,
> NodeRefList& theResult,
> bool * const pbFound )
> {
> *pbFound = false;
>
> if ( (XalanDocument *) NULL != pXalanDoc )
> {
> // attempt to locate the requested context node
> XalanNode* const theContextNode =
> pMyXPathEvaluator->selectSingleNode( *pMyXalanSourceTreeDOMSupport,
> pXalanDoc,
> xdsContext.c_str(),
>
> pXalanDoc->getDocumentElement() );
>
> evaluateQuery( pXalanDoc,
> theContextNode, xdsContext, theResult, pbFound );
> }
> }
>
> and, of course, one more to go from const char*'s to XalanDOMString's (but
> that is just a one line wrapper which hides the XalanDOMString(const char *
> const).c_str() junk from the "client".
>
> On Thursday 16 June 2005 08:08 am, Lonnie VanZandt wrote:
> > The method which calls selectNodeList (and wherein selectNodeList dies):
> >
> > //! evaluate an XPath expression for a given XalanDOM and a given
> > starting context
> > void evaluateQuery( XalanDocument * const pXalanDoc,
> > XalanNode * const theContextNode,
> > XalanDOMString xdsPathExpr,
> > NodeRefList& theResult,
> > bool * const pbFound )
> > {
> > *pbFound = false;
> >
> > if ( (XalanDocument * const) NULL != pXalanDoc )
> > {
> > // a null node indicates that the context couldn't be found
> > if ( (XalanNode * const) NULL != theContextNode)
> > {
> > // OK, let's evaluate the expression...
> > pMyXPathEvaluator->selectNodeList(
> > theResult,
> > *pMyXalanSourceTreeDOMSupport,
> > theContextNode,
> > xdsPathExpr.c_str(),
> > pXalanDoc->getDocumentElement() );
> >
> > * pbFound = ( !theResult.empty() );
> > }
> > }
> > }
> >
> > The calling method (in a derived class which contains the above method):
> >
> > NodeRefList nodeRefList;
> > bool bFound = false;
> > pDBDXMLProcessor->evaluateQuery( pRequestXalanDoc,
> > "/casperAPI", "trigger", nodeRefList, &bFound );
> >
> > The context initialization in the base class' constructor:
> >
> > try
> > {
> > XMLPlatformUtils::Initialize();
> >
> > // Initialize Xalan.
> > XalanTransformer::initialize();
> >
> > // initialize the XalanSourceTree
> > pMyXalanSourceTreeInit = new XalanSourceTreeInit();
> >
> > // We'll use these to parse the XML file.
> > pMyXalanSourceTreeDOMSupport = new XalanSourceTreeDOMSupport();
> > pMyXalanSourceTreeParserLiaison = new
> > XalanSourceTreeParserLiaison( *pMyXalanSourceTreeDOMSupport );
> >
> > // Hook the two DOM manager and the Xalan parser together
> >
> > pMyXalanSourceTreeDOMSupport->setParserLiaison(
> > pMyXalanSourceTreeParserLiaison );
> >
> > // our XPathEvaluator
> > XPathEvaluator::initialize();
> > pMyXPathEvaluator = new XPathEvaluator();
> >
> > // instantiate an Xalan Transformer
> > pMyXalanTransformer = new XalanTransformer();
> > }
> > catch (const XMLException& toCatch)
> > {
> > std::cerr << "Xalan and Xerces initialization failed. Error code
> > was "
> > << toCatch.getCode() << "." << std::endl;
> >
> > //throw toCatch;
> > }
> >
> > And, finally, parsing of pRequestXalanDoc:
> >
> > //! parse the given XML input into a read-only Xalan DOM Document
> > XalanDocument * const parseString( const char * const
> > sXmlInputCharArray ) const
> > {
> > // wrap the input string within a stream handler
> > std::istringstream issXml( sXmlInputCharArray );
> >
> > // promote the input XML character buffer into an XSLTInputSource
> > const XSLTInputSource xisXml( issXml );
> >
> > XalanDocument * const pXalanDoc =
> > pMyXalanSourceTreeParserLiaison->parseXMLStream( xisXml );
> >
> > return pXalanDoc;
> > }
> >
> > On Thursday 16 June 2005 07:59 am, Axel Weiß wrote:
> > > Lonnie VanZandt wrote:
> > > > Not quite, the crash still occurs in the same location - but
> > > > assuredly it is a good idea to call that initialize() method
> > > > nevertheless.
> > >
> > > Hi Lonnie,
> > >
> > > would you, please, provide us with some example you're working on?
> > >
> > > Just to be in-line with what you're telling about...
> > >
> > > Cheers,
> > > Axel
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xalan-dev-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xalan-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: XPathEvaluator sigsegv's on NodeRefList::operator=
Posted by Lonnie VanZandt <lo...@ngc.com>.
Oh, there's an intervening method which resolves the context node from a
XalanDOMString expression. That is:
//! evaluate an XPath expression for a given XalanDOM and a given starting
context
void evaluateQuery( XalanDocument * const pXalanDoc,
XalanDOMString xdsContext,
XalanDOMString xdsPathExpr,
NodeRefList& theResult,
bool * const pbFound )
{
*pbFound = false;
if ( (XalanDocument *) NULL != pXalanDoc )
{
// attempt to locate the requested context node
XalanNode* const theContextNode = pMyXPathEvaluator->selectSingleNode(
*pMyXalanSourceTreeDOMSupport,
pXalanDoc,
xdsContext.c_str(),
pXalanDoc->getDocumentElement() );
evaluateQuery( pXalanDoc,
theContextNode, xdsContext, theResult, pbFound );
}
}
and, of course, one more to go from const char*'s to XalanDOMString's (but
that is just a one line wrapper which hides the XalanDOMString(const char *
const).c_str() junk from the "client".
On Thursday 16 June 2005 08:08 am, Lonnie VanZandt wrote:
> The method which calls selectNodeList (and wherein selectNodeList dies):
>
> //! evaluate an XPath expression for a given XalanDOM and a given
> starting context
> void evaluateQuery( XalanDocument * const pXalanDoc,
> XalanNode * const theContextNode,
> XalanDOMString xdsPathExpr,
> NodeRefList& theResult,
> bool * const pbFound )
> {
> *pbFound = false;
>
> if ( (XalanDocument * const) NULL != pXalanDoc )
> {
> // a null node indicates that the context couldn't be found
> if ( (XalanNode * const) NULL != theContextNode)
> {
> // OK, let's evaluate the expression...
> pMyXPathEvaluator->selectNodeList(
> theResult,
> *pMyXalanSourceTreeDOMSupport,
> theContextNode,
> xdsPathExpr.c_str(),
> pXalanDoc->getDocumentElement() );
>
> * pbFound = ( !theResult.empty() );
> }
> }
> }
>
> The calling method (in a derived class which contains the above method):
>
> NodeRefList nodeRefList;
> bool bFound = false;
> pDBDXMLProcessor->evaluateQuery( pRequestXalanDoc,
> "/casperAPI", "trigger", nodeRefList, &bFound );
>
> The context initialization in the base class' constructor:
>
> try
> {
> XMLPlatformUtils::Initialize();
>
> // Initialize Xalan.
> XalanTransformer::initialize();
>
> // initialize the XalanSourceTree
> pMyXalanSourceTreeInit = new XalanSourceTreeInit();
>
> // We'll use these to parse the XML file.
> pMyXalanSourceTreeDOMSupport = new XalanSourceTreeDOMSupport();
> pMyXalanSourceTreeParserLiaison = new
> XalanSourceTreeParserLiaison( *pMyXalanSourceTreeDOMSupport );
>
> // Hook the two DOM manager and the Xalan parser together
>
> pMyXalanSourceTreeDOMSupport->setParserLiaison(
> pMyXalanSourceTreeParserLiaison );
>
> // our XPathEvaluator
> XPathEvaluator::initialize();
> pMyXPathEvaluator = new XPathEvaluator();
>
> // instantiate an Xalan Transformer
> pMyXalanTransformer = new XalanTransformer();
> }
> catch (const XMLException& toCatch)
> {
> std::cerr << "Xalan and Xerces initialization failed. Error code
> was "
> << toCatch.getCode() << "." << std::endl;
>
> //throw toCatch;
> }
>
> And, finally, parsing of pRequestXalanDoc:
>
> //! parse the given XML input into a read-only Xalan DOM Document
> XalanDocument * const parseString( const char * const
> sXmlInputCharArray ) const
> {
> // wrap the input string within a stream handler
> std::istringstream issXml( sXmlInputCharArray );
>
> // promote the input XML character buffer into an XSLTInputSource
> const XSLTInputSource xisXml( issXml );
>
> XalanDocument * const pXalanDoc =
> pMyXalanSourceTreeParserLiaison->parseXMLStream( xisXml );
>
> return pXalanDoc;
> }
>
> On Thursday 16 June 2005 07:59 am, Axel Weiß wrote:
> > Lonnie VanZandt wrote:
> > > Not quite, the crash still occurs in the same location - but assuredly
> > > it is a good idea to call that initialize() method nevertheless.
> >
> > Hi Lonnie,
> >
> > would you, please, provide us with some example you're working on?
> >
> > Just to be in-line with what you're telling about...
> >
> > Cheers,
> > Axel
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xalan-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: XPathEvaluator sigsegv's on NodeRefList::operator=
Posted by Lonnie VanZandt <lo...@ngc.com>.
The method which calls selectNodeList (and wherein selectNodeList dies):
//! evaluate an XPath expression for a given XalanDOM and a given starting
context
void evaluateQuery( XalanDocument * const pXalanDoc,
XalanNode * const theContextNode,
XalanDOMString xdsPathExpr,
NodeRefList& theResult,
bool * const pbFound )
{
*pbFound = false;
if ( (XalanDocument * const) NULL != pXalanDoc )
{
// a null node indicates that the context couldn't be found
if ( (XalanNode * const) NULL != theContextNode)
{
// OK, let's evaluate the expression...
pMyXPathEvaluator->selectNodeList(
theResult,
*pMyXalanSourceTreeDOMSupport,
theContextNode,
xdsPathExpr.c_str(),
pXalanDoc->getDocumentElement() );
* pbFound = ( !theResult.empty() );
}
}
}
The calling method (in a derived class which contains the above method):
NodeRefList nodeRefList;
bool bFound = false;
pDBDXMLProcessor->evaluateQuery( pRequestXalanDoc,
"/casperAPI", "trigger", nodeRefList, &bFound );
The context initialization in the base class' constructor:
try
{
XMLPlatformUtils::Initialize();
// Initialize Xalan.
XalanTransformer::initialize();
// initialize the XalanSourceTree
pMyXalanSourceTreeInit = new XalanSourceTreeInit();
// We'll use these to parse the XML file.
pMyXalanSourceTreeDOMSupport = new XalanSourceTreeDOMSupport();
pMyXalanSourceTreeParserLiaison = new
XalanSourceTreeParserLiaison( *pMyXalanSourceTreeDOMSupport );
// Hook the two DOM manager and the Xalan parser together
pMyXalanSourceTreeDOMSupport->setParserLiaison( pMyXalanSourceTreeParserLiaison );
// our XPathEvaluator
XPathEvaluator::initialize();
pMyXPathEvaluator = new XPathEvaluator();
// instantiate an Xalan Transformer
pMyXalanTransformer = new XalanTransformer();
}
catch (const XMLException& toCatch)
{
std::cerr << "Xalan and Xerces initialization failed. Error code was
"
<< toCatch.getCode() << "." << std::endl;
//throw toCatch;
}
And, finally, parsing of pRequestXalanDoc:
//! parse the given XML input into a read-only Xalan DOM Document
XalanDocument * const parseString( const char * const sXmlInputCharArray )
const
{
// wrap the input string within a stream handler
std::istringstream issXml( sXmlInputCharArray );
// promote the input XML character buffer into an XSLTInputSource
const XSLTInputSource xisXml( issXml );
XalanDocument * const pXalanDoc =
pMyXalanSourceTreeParserLiaison->parseXMLStream( xisXml );
return pXalanDoc;
}
On Thursday 16 June 2005 07:59 am, Axel Weiß wrote:
> Lonnie VanZandt wrote:
> > Not quite, the crash still occurs in the same location - but assuredly
> > it is a good idea to call that initialize() method nevertheless.
>
> Hi Lonnie,
>
> would you, please, provide us with some example you're working on?
>
> Just to be in-line with what you're telling about...
>
> Cheers,
> Axel
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: XPathEvaluator sigsegv's on NodeRefList::operator=
Posted by Axel Weiß <aw...@informatik.hu-berlin.de>.
Lonnie VanZandt wrote:
> Not quite, the crash still occurs in the same location - but assuredly
> it is a good idea to call that initialize() method nevertheless.
Hi Lonnie,
would you, please, provide us with some example you're working on?
Just to be in-line with what you're telling about...
Cheers,
Axel
--
Humboldt-Universität zu Berlin
Institut für Informatik
Signalverarbeitung und Mustererkennung
Dipl.-Inf. Axel Weiß
Rudower Chaussee 25
12489 Berlin-Adlershof
+49-30-2093-3050
** www.freesp.de **
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: XPathEvaluator sigsegv's on NodeRefList::operator=
Posted by Lonnie VanZandt <lo...@ngc.com>.
Not quite, the crash still occurs in the same location - but assuredly it is a
good idea to call that initialize() method nevertheless.
On Thursday 16 June 2005 06:53 am, Lonnie VanZandt wrote:
> Ah, a strong indicator of pilot error: there is (yet another)
> XPathEvaluator::initialize() static method which I overlooked, forgot to
> call, and is probably at least a source of potential problems if not this
> actual problem.
>
> On Thursday 16 June 2005 06:37 am, Lonnie VanZandt wrote:
> > Hmm, if I replace the selectNodeList call with a call to evaluate(), the
> > evaluate call succeeds without a crash. The XObjectPtr I get back has a
> > non-null get() value. However, if I try to convert that XObjectPtr to a
> > nodeset via thePtr->nodeset() (just as selectNodeList does) then,
> > immediately, the crash occurs. So, clearly, the XObjectPtr isn't pointing
> > to a valid NodeRefList nodeset - but, then, what is it pointing to?
> >
> > On Thursday 16 June 2005 06:12 am, Lonnie VanZandt wrote:
> > > Using some code very similar to the samples/SerializeNodeSet example, I
> > > currently get a core dump which shows that NodeRefList::operator= tried
> > > to dereference a null. (This is Xalan C++ 1.9).
> > >
> > > The preceding call to selectSingleNode returned a non-null contextNode
> > > for a non-null XalanDocument but the selectNodeList call which is given
> > > that contextNode and an empty (getLength=0) NodeRefList dumps core.
> > >
> > > I gather that the internal evaluate call is returning an XObjectPtr
> > > whose member pointer is 0. Then when operator= tries to copy
> > > theResult->nodeset() into the NodeRefList& which I pass in, the null
> > > derefence "fires".
> > >
> > > Now, it may be that there is a scoping or a memory manager issue which
> > > I've overlooked while reading the Xalan C++ API, sample code, and
> > > mailing lists.
> > >
> > > My XPathEvaluator, the NodeRefList, the source XalanDocument, and the
> > > context node all have greater, outer scope when selectNodeList gets
> > > called. Also, I can dereference the passed in NodeRefList& (via
> > > myNodeRefList.getLength()) safely immediately before the selectNodeList
> > > call within the same scope.
> > >
> > > Has this (likely pilot) error been encountered before?
> > >
> > > Perhaps my XalanDocument, constructed via the parserLiaison
> > > parseXMLStream method is somehow malformed? (The original source XML is
> > > assuredly well-formed because a peer XalanTransformer has no problems
> > > translating it from its original XSLTInputSource...)
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
> > > For additional commands, e-mail: xalan-dev-help@xml.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xalan-dev-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xalan-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: XPathEvaluator sigsegv's on NodeRefList::operator=
Posted by Lonnie VanZandt <lo...@ngc.com>.
Excellent design practices and I'm not really a hacker, I only play one for
this current employer.
The incoming XML is truly trivial and the fault occurs before the XSLT
transformer runs the XSLT, so either the code I have written is flawed (most
likely) or it has stumbled over a real Xalan XPath bug.
No, we can't switch to pathan for schedule and feature reasons.
On Thursday 16 June 2005 12:10 pm, Axel Weiß wrote:
> Lonnie VanZandt wrote:
> > No, I can't share those because they are highly proprietary. But, they
> > are actually irrelevant to conceptual work to be done. Which I can
> > discuss.
> >
> > I have distributed servers which pass XML strings as their messages.
> > The servers are mostly stateless and transform an input XML into an
> > output XML based on XSLT-scripted "business logic".
> >
> > The transformer is humming along fine.
> >
> > However, occassionally, a server needs to peek into an incoming XML
> > request or an outgoing XML reply in order to do content-specific
> > processing above and beyond what the XSLT can do (such as determining
> > destinations and session management).
> >
> > So, rather than code up a mess of DOM traversal code, I need/want to
> > ask an XPathEvaluator to evaluate some "peeks" into the source and
> > output XML documents.
> >
> > Therefore, a string of XML arrives on a socket, I parse the XML into a
> > XalanDocument, I (try to) peek into the request with XPathEvaluator, I
> > get any state I need, I set XSLT stylesheet parameters, I let
> > XalanTransformer do its transformation, I (try to) peek into reply
> > with XPathEvaluator, I get any state I need, and I send off the reply
> > XML to the proper socket.
> >
> > I have two wishes:
> >
> > 1. That XPath::executeMore not return a null nodeset() or, at least,
> > that XPathEvaluator::selectNodeList not try to nodeset() on a
> > *XObjectPtr which isn't actually a NodeRefList.
> >
> > 2. To have the XalanTransformer use its parseSource method to parse
> > the input XML once for both the XPath query and then for the
> > transform() method (rather than constructing a separate XalanDocument
> > with the parserLiaison just for the XPath evaluator) and then use the
> > XalanTransformer to parse the reply XML so that the post-transform
> > XPath query can use that without having to construct a new
> > XalanDocument for the output string.
> >
> > Makes sense?
>
> That sounds all reasonable to me. However, when I develop some complex
> concepts (and the above is fairly complex ;), I usually try to break
> down some simple examples that show 1. the principles and 2. the core
> algorithms. I usually enforce this when I run into problems and want to
> communicate and discuss some non-obvious solutions.
>
> If I got you right, the problem is located in the (non-) ability of xalan
> to evaluate some XPath expression. Anything special with this
> expression? Can you possibly simplify the context where you encounter
> the problem, to a xml-file/xpath-expression pair that can reproduce the
> erroneous behaviour (and that is not top-secret;)?
>
> I have not very much experience with xpath-magics, just enough to be able
> to write the stylesheets I demand. I heard about that xerces has very
> little xpath support, xalan a bit more. But - did you already try
> pathan? Maybe it's worth a look...
>
> Cheers,
> Axel
>
> (You need not CC me, 'cause I'm subscribed here ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: XPathEvaluator sigsegv's on NodeRefList::operator=
Posted by Axel Weiß <aw...@informatik.hu-berlin.de>.
Lonnie VanZandt wrote:
> No, I can't share those because they are highly proprietary. But, they
> are actually irrelevant to conceptual work to be done. Which I can
> discuss.
>
> I have distributed servers which pass XML strings as their messages.
> The servers are mostly stateless and transform an input XML into an
> output XML based on XSLT-scripted "business logic".
>
> The transformer is humming along fine.
>
> However, occassionally, a server needs to peek into an incoming XML
> request or an outgoing XML reply in order to do content-specific
> processing above and beyond what the XSLT can do (such as determining
> destinations and session management).
>
> So, rather than code up a mess of DOM traversal code, I need/want to
> ask an XPathEvaluator to evaluate some "peeks" into the source and
> output XML documents.
>
> Therefore, a string of XML arrives on a socket, I parse the XML into a
> XalanDocument, I (try to) peek into the request with XPathEvaluator, I
> get any state I need, I set XSLT stylesheet parameters, I let
> XalanTransformer do its transformation, I (try to) peek into reply
> with XPathEvaluator, I get any state I need, and I send off the reply
> XML to the proper socket.
>
> I have two wishes:
>
> 1. That XPath::executeMore not return a null nodeset() or, at least,
> that XPathEvaluator::selectNodeList not try to nodeset() on a
> *XObjectPtr which isn't actually a NodeRefList.
>
> 2. To have the XalanTransformer use its parseSource method to parse
> the input XML once for both the XPath query and then for the
> transform() method (rather than constructing a separate XalanDocument
> with the parserLiaison just for the XPath evaluator) and then use the
> XalanTransformer to parse the reply XML so that the post-transform
> XPath query can use that without having to construct a new
> XalanDocument for the output string.
>
> Makes sense?
That sounds all reasonable to me. However, when I develop some complex
concepts (and the above is fairly complex ;), I usually try to break
down some simple examples that show 1. the principles and 2. the core
algorithms. I usually enforce this when I run into problems and want to
communicate and discuss some non-obvious solutions.
If I got you right, the problem is located in the (non-) ability of xalan
to evaluate some XPath expression. Anything special with this
expression? Can you possibly simplify the context where you encounter
the problem, to a xml-file/xpath-expression pair that can reproduce the
erroneous behaviour (and that is not top-secret;)?
I have not very much experience with xpath-magics, just enough to be able
to write the stylesheets I demand. I heard about that xerces has very
little xpath support, xalan a bit more. But - did you already try
pathan? Maybe it's worth a look...
Cheers,
Axel
(You need not CC me, 'cause I'm subscribed here ;)
--
Humboldt-Universität zu Berlin
Institut für Informatik
Signalverarbeitung und Mustererkennung
Dipl.-Inf. Axel Weiß
Rudower Chaussee 25
12489 Berlin-Adlershof
+49-30-2093-3050
** www.freesp.de **
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: XPathEvaluator sigsegv's on NodeRefList::operator=
Posted by da...@us.ibm.com.
> Hmm, if I move away from the parserLiaison objects for constructing the
> XalanDocuments of the XML strings, then I need to find an
> XalanSourceTreeDOMSupport for the XPathEvaluator calls. I have to go
review
> the APIs to see where to borrow/construct one...
You have two options here. One is to simply create an instance of
XalanSourceTreeDOMSupport and use that. The other is to ask the
XalanParsedSource instance to create a XalanParsedSourceHelper instance by
called XalanParsedSource::createHelper(). You'll notice that
XalanParsedSourceHelper has a handy member function called getDOMSupport()
that returns a reference to the associated DOMSupport instance.
The first option is easier, but the second is arguably more correct. If
you choose the second option, remember to delete the
XalanParsedSourceHelper when you destroy the associated XalanParsedSource
instance.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: XPathEvaluator sigsegv's on NodeRefList::operator=
Posted by Lonnie VanZandt <lo...@ngc.com>.
Hmm, if I move away from the parserLiaison objects for constructing the
XalanDocuments of the XML strings, then I need to find an
XalanSourceTreeDOMSupport for the XPathEvaluator calls. I have to go review
the APIs to see where to borrow/construct one...
On Thursday 16 June 2005 01:09 pm, Lonnie VanZandt wrote:
> David,
>
> Thank you for responding as I always await your expert and concise advice
> on Xalan-C++.
>
> A bit of XML which causes the problem might be:
> <casperAPI><trigger><oneMoreElement/></trigger></casperAPI>. And note that
> no <?xml...> PI precedes this.
>
> After parsing the above string with the parserLiaison (see SimpleXPathAPI
> for the details), I can successfully use calls like
> getDocumentElement()->getNodeName() to get strings such as <casperAPI> and
> so I feel somewhat confident that the XalanDocument that I pass to
> XPathEvaluator::selectSingleNode and selectNodeList is well-formed.
>
> As for calling XPath::executeMore(), O, good grief! I wouldn't dream of
> it. I've simply traced through the Xalan source code to try to learn where
> NodeRefList::operator= might be getting passed an invalid rhs from an
> XObjectPtr.
>
> Because I can implement the steps of selectNodeList in my code, without
> error, up to the point of the line "result = (theResult->nodeset()); and
> because the gdb of the core reports that the fault occurs in the
> NodeRefList::operator= routine, and because if I add that same attempt to
> call the nodeset() method of the target XObject the code then similarly
> sigsegv's, I am rather confident that something about "theResult" is
> unexpected. As this is down inside Xalan internal code, I would agree that
> it is at least something which the Xalan code should guard against.
> However, I will not be surprised if I learn that the reason this is
> occuring is due to out-of-scoping issue or improper initialization issue
> which is miscoded by me earlier in the ultimate parent object's lifetime.
>
> As for parseSource, yes, it is trivial, isn't it? And pleasantly so. I went
> ahead and recoded the xml string parsers to use that approach and it all
> works nicely. So, I can get rid of all the parserLiaison stuff which isn't
> necessary (for this use case anyway.)
>
> I will strive to get a test case and enter a jira bug...
>
> On Thursday 16 June 2005 12:38 pm, david_n_bertoni@us.ibm.com wrote:
> > > No, I can't share those because they are highly proprietary. But, they
> >
> > are
> >
> > > actually irrelevant to conceptual work to be done. Which I can discuss.
> >
> > But surely you can come up with a trivial test case that reproduces the
> > bug?
> >
> > > 1. That XPath::executeMore not return a null nodeset() or, at least,
> >
> > that
> >
> > > XPathEvaluator::selectNodeList not try to nodeset() on a *XObjectPtr
> >
> > which
> >
> > > isn't actually a NodeRefList.
> >
> > XPath::executeMore() is an internal routine, and you should not attempt
> > to call it. If XPathEvaluator::selectNodeList() is using an XObjectPtr
> > instance incorrectly, then that's a bug and we will fix it. Just create
> > a Jira report, and attach a minimal set of input data, and some
> > self-contained code that reproduces the problem.
> >
> > > 2. To have the XalanTransformer use its parseSource method to parse the
> >
> > input
> >
> > > XML once for both the XPath query and then for the transform() method
> >
> > (rather
> >
> > > than constructing a separate XalanDocument with the parserLiaison just
> >
> > for
> >
> > > the XPath evaluator) and then use the XalanTransformer to parse the
> >
> > reply XML
> >
> > > so that the post-transform XPath query can use that without having to
> > > construct a new XalanDocument for the output string.
> >
> > This is trivial. Call XalanTransformer::parseSource(), which create an
> > instance of XalanParsedSource for you. Then, you can call
> > XalanParsedSource::getDocument() to get the underlying XalanDocument
> > instance, which you can pass to any of the XPathEvaluator member
> > functions.
> >
> > Dave
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xalan-dev-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xalan-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: XPathEvaluator sigsegv's on NodeRefList::operator=
Posted by Lonnie VanZandt <lo...@ngc.com>.
David,
Forgive me, I am too diplomatic. Yes, the failing call is in Xalan source and
follows the code flow: XPathEvaluator::selectNodeList --
XPathEvaluator::evaluate -- XPath::execute -- XPath::executeMore -- ... --
XPathEvaluator::selectNodeList and then result = (theResult->nodeset()). This
statement, in selectNodeList, results in a call to NodeRefList::operator=
which does the NULL pointer dereference.
The mailing list received my stream of messages as I learned more about where
the problem is occuring. I was able to verify where it was occuring by
writing the steps of selectNodeList in my own program (just the evaluate and
then the "result" assignment).
It would be far easier for me if my client's target system had compilation and
debugger tools on it. As it is, I cross compile on my development system and
run on the target. To do any debugging (other than a post-crash core
examination without Xalan library symbols) I add good old printf tracepoints
to the source.
Today I will see if I can compile the sample SerializeNodeSet app (it isn't as
easy as just runConfigure, make since I have to move it into our cross build
setup...) and see if it runs into the same problem on which the truly trivial
XML input and XPath expression the crash occurs.
Thanks for the advice on the XalanSourceTreeDOMSupport technique. I'll choose
the correct, harder method...
On Thursday 16 June 2005 03:17 pm, david_n_bertoni@us.ibm.com wrote:
> > As for calling XPath::executeMore(), O, good grief! I wouldn't dream of
>
> it.
>
> Good -- we don't want you dreaming about the forbidden! ;-)
>
> > I've simply traced through the Xalan source code to try to learn where
> > NodeRefList::operator= might be getting passed an invalid rhs from an
> > XObjectPtr.
> >
> > Because I can implement the steps of selectNodeList in my code, without
> >
> > error, up to the point of the line "result = (theResult->nodeset()); and
> >
> > because the gdb of the core reports that the fault occurs in the
> > NodeRefList::operator= routine, and because if I add that same attempt
>
> to
>
> > call the nodeset() method of the target XObject the code then similarly
> > sigsegv's, I am rather confident that something about "theResult" is
> > unexpected. As this is down inside Xalan internal code, I would agree
>
> that it
>
> > is at least something which the Xalan code should guard against.
>
> However, I
>
> > will not be surprised if I learn that the reason this is occuring is due
>
> to
>
> > out-of-scoping issue or improper initialization issue which is miscoded
>
> by me
>
> > earlier in the ultimate parent object's lifetime.
>
> But the relevant issue is whether "result = (theResult->nodeset())" is
> code inside of XPathEvaluator. I do see a line of code like that in
> XPathEvaluator.cpp, but I can't really tell if that's what you're
> referring to.
>
> Please don't take this "the wrong way," but you have posted now 12 emails
> today about this problem. Remember this is a volunteer project, so
> people's time is often very limited. It would be very helpful in the
> future if you would gather your thoughts and the relevant information, and
> try to be very organized and concise when you post. Although
> "stream-of-consciousness" makes for more interesting real-time
> communication, it's really difficult in the forum of a mailing list,
> because it forces everyone on the list to read and combine every one of
> your posts to have an idea of what you're trying to say.
>
> > As for parseSource, yes, it is trivial, isn't it? And pleasantly so. I
>
> went
>
> > ahead and recoded the xml string parsers to use that approach and it all
> >
> > works nicely. So, I can get rid of all the parserLiaison stuff which
>
> isn't
>
> > necessary (for this use case anyway.)
>
> Good.
>
> > I will strive to get a test case and enter a jira bug...
>
> That would be fantastic. Also, can you post the stack trace that gdb
> reports from the core file?
>
> Thanks!
>
> Dave
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xalan-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: XPathEvaluator sigsegv's on NodeRefList::operator=
Posted by Lonnie VanZandt <lo...@ngc.com>.
This is interesting:
Back in the application which crashes with a selectNodeList call...
If I pass a NodeRefList& from within the same function that calls
selectNodeList() rather than one passed from another object which is a client
of the object which encapsulates the Xalan transformation stuff, then the
crash does not happen.
The "external" NodeRefList instance has not gone out of scope (and been
deconstructed) at the time of the selectNodeList call, so something about its
creation context makes it different than the "internal" one.
Is there something about the memory manager mechanics which I should better
understand?
On Friday 17 June 2005 03:10 pm, Lonnie VanZandt wrote:
> David,
>
> Well, I am comforted to see that the SerializeNodeSet sample,
> cross-compiled and running on the target, when given a similarly simple
> input XML string, properly evaluates the XPath expression and doesn't
> crash.
>
> This indicates that the issue has nothing to do with the crossbuild
> environment and most likely lies in the set up in my code. (I am not
> surprised but remain confused.)
>
> Should I learn more, I'll comment here later...
>
> On Thursday 16 June 2005 03:17 pm, david_n_bertoni@us.ibm.com wrote:
> > > As for calling XPath::executeMore(), O, good grief! I wouldn't dream of
> >
> > it.
> >
> > Good -- we don't want you dreaming about the forbidden! ;-)
> >
> > > I've simply traced through the Xalan source code to try to learn where
> > > NodeRefList::operator= might be getting passed an invalid rhs from an
> > > XObjectPtr.
> > >
> > > Because I can implement the steps of selectNodeList in my code,
> > > without
> > >
> > > error, up to the point of the line "result = (theResult->nodeset());
> > > and
> > >
> > > because the gdb of the core reports that the fault occurs in the
> > > NodeRefList::operator= routine, and because if I add that same attempt
> >
> > to
> >
> > > call the nodeset() method of the target XObject the code then similarly
> > > sigsegv's, I am rather confident that something about "theResult" is
> > > unexpected. As this is down inside Xalan internal code, I would agree
> >
> > that it
> >
> > > is at least something which the Xalan code should guard against.
> >
> > However, I
> >
> > > will not be surprised if I learn that the reason this is occuring is
> > > due
> >
> > to
> >
> > > out-of-scoping issue or improper initialization issue which is miscoded
> >
> > by me
> >
> > > earlier in the ultimate parent object's lifetime.
> >
> > But the relevant issue is whether "result = (theResult->nodeset())" is
> > code inside of XPathEvaluator. I do see a line of code like that in
> > XPathEvaluator.cpp, but I can't really tell if that's what you're
> > referring to.
> >
> > Please don't take this "the wrong way," but you have posted now 12 emails
> > today about this problem. Remember this is a volunteer project, so
> > people's time is often very limited. It would be very helpful in the
> > future if you would gather your thoughts and the relevant information,
> > and try to be very organized and concise when you post. Although
> > "stream-of-consciousness" makes for more interesting real-time
> > communication, it's really difficult in the forum of a mailing list,
> > because it forces everyone on the list to read and combine every one of
> > your posts to have an idea of what you're trying to say.
> >
> > > As for parseSource, yes, it is trivial, isn't it? And pleasantly so. I
> >
> > went
> >
> > > ahead and recoded the xml string parsers to use that approach and it
> > > all
> > >
> > > works nicely. So, I can get rid of all the parserLiaison stuff which
> >
> > isn't
> >
> > > necessary (for this use case anyway.)
> >
> > Good.
> >
> > > I will strive to get a test case and enter a jira bug...
> >
> > That would be fantastic. Also, can you post the stack trace that gdb
> > reports from the core file?
> >
> > Thanks!
> >
> > Dave
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xalan-dev-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xalan-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: XPathEvaluator sigsegv's on NodeRefList::operator=
Posted by Lonnie VanZandt <lo...@ngc.com>.
David,
Well, I am comforted to see that the SerializeNodeSet sample, cross-compiled
and running on the target, when given a similarly simple input XML string,
properly evaluates the XPath expression and doesn't crash.
This indicates that the issue has nothing to do with the crossbuild
environment and most likely lies in the set up in my code. (I am not
surprised but remain confused.)
Should I learn more, I'll comment here later...
On Thursday 16 June 2005 03:17 pm, david_n_bertoni@us.ibm.com wrote:
> > As for calling XPath::executeMore(), O, good grief! I wouldn't dream of
>
> it.
>
> Good -- we don't want you dreaming about the forbidden! ;-)
>
> > I've simply traced through the Xalan source code to try to learn where
> > NodeRefList::operator= might be getting passed an invalid rhs from an
> > XObjectPtr.
> >
> > Because I can implement the steps of selectNodeList in my code, without
> >
> > error, up to the point of the line "result = (theResult->nodeset()); and
> >
> > because the gdb of the core reports that the fault occurs in the
> > NodeRefList::operator= routine, and because if I add that same attempt
>
> to
>
> > call the nodeset() method of the target XObject the code then similarly
> > sigsegv's, I am rather confident that something about "theResult" is
> > unexpected. As this is down inside Xalan internal code, I would agree
>
> that it
>
> > is at least something which the Xalan code should guard against.
>
> However, I
>
> > will not be surprised if I learn that the reason this is occuring is due
>
> to
>
> > out-of-scoping issue or improper initialization issue which is miscoded
>
> by me
>
> > earlier in the ultimate parent object's lifetime.
>
> But the relevant issue is whether "result = (theResult->nodeset())" is
> code inside of XPathEvaluator. I do see a line of code like that in
> XPathEvaluator.cpp, but I can't really tell if that's what you're
> referring to.
>
> Please don't take this "the wrong way," but you have posted now 12 emails
> today about this problem. Remember this is a volunteer project, so
> people's time is often very limited. It would be very helpful in the
> future if you would gather your thoughts and the relevant information, and
> try to be very organized and concise when you post. Although
> "stream-of-consciousness" makes for more interesting real-time
> communication, it's really difficult in the forum of a mailing list,
> because it forces everyone on the list to read and combine every one of
> your posts to have an idea of what you're trying to say.
>
> > As for parseSource, yes, it is trivial, isn't it? And pleasantly so. I
>
> went
>
> > ahead and recoded the xml string parsers to use that approach and it all
> >
> > works nicely. So, I can get rid of all the parserLiaison stuff which
>
> isn't
>
> > necessary (for this use case anyway.)
>
> Good.
>
> > I will strive to get a test case and enter a jira bug...
>
> That would be fantastic. Also, can you post the stack trace that gdb
> reports from the core file?
>
> Thanks!
>
> Dave
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xalan-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: XPathEvaluator sigsegv's on NodeRefList::operator=
Posted by da...@us.ibm.com.
> As for calling XPath::executeMore(), O, good grief! I wouldn't dream of
it.
Good -- we don't want you dreaming about the forbidden! ;-)
> I've simply traced through the Xalan source code to try to learn where
> NodeRefList::operator= might be getting passed an invalid rhs from an
> XObjectPtr.
>
> Because I can implement the steps of selectNodeList in my code, without
> error, up to the point of the line "result = (theResult->nodeset()); and
> because the gdb of the core reports that the fault occurs in the
> NodeRefList::operator= routine, and because if I add that same attempt
to
> call the nodeset() method of the target XObject the code then similarly
> sigsegv's, I am rather confident that something about "theResult" is
> unexpected. As this is down inside Xalan internal code, I would agree
that it
> is at least something which the Xalan code should guard against.
However, I
> will not be surprised if I learn that the reason this is occuring is due
to
> out-of-scoping issue or improper initialization issue which is miscoded
by me
> earlier in the ultimate parent object's lifetime.
But the relevant issue is whether "result = (theResult->nodeset())" is
code inside of XPathEvaluator. I do see a line of code like that in
XPathEvaluator.cpp, but I can't really tell if that's what you're
referring to.
Please don't take this "the wrong way," but you have posted now 12 emails
today about this problem. Remember this is a volunteer project, so
people's time is often very limited. It would be very helpful in the
future if you would gather your thoughts and the relevant information, and
try to be very organized and concise when you post. Although
"stream-of-consciousness" makes for more interesting real-time
communication, it's really difficult in the forum of a mailing list,
because it forces everyone on the list to read and combine every one of
your posts to have an idea of what you're trying to say.
> As for parseSource, yes, it is trivial, isn't it? And pleasantly so. I
went
> ahead and recoded the xml string parsers to use that approach and it all
> works nicely. So, I can get rid of all the parserLiaison stuff which
isn't
> necessary (for this use case anyway.)
Good.
> I will strive to get a test case and enter a jira bug...
That would be fantastic. Also, can you post the stack trace that gdb
reports from the core file?
Thanks!
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: XPathEvaluator sigsegv's on NodeRefList::operator=
Posted by Lonnie VanZandt <lo...@ngc.com>.
David,
Thank you for responding as I always await your expert and concise advice on
Xalan-C++.
A bit of XML which causes the problem might be:
<casperAPI><trigger><oneMoreElement/></trigger></casperAPI>. And note that no
<?xml...> PI precedes this.
After parsing the above string with the parserLiaison (see SimpleXPathAPI for
the details), I can successfully use calls like
getDocumentElement()->getNodeName() to get strings such as <casperAPI> and so
I feel somewhat confident that the XalanDocument that I pass to
XPathEvaluator::selectSingleNode and selectNodeList is well-formed.
As for calling XPath::executeMore(), O, good grief! I wouldn't dream of it.
I've simply traced through the Xalan source code to try to learn where
NodeRefList::operator= might be getting passed an invalid rhs from an
XObjectPtr.
Because I can implement the steps of selectNodeList in my code, without
error, up to the point of the line "result = (theResult->nodeset()); and
because the gdb of the core reports that the fault occurs in the
NodeRefList::operator= routine, and because if I add that same attempt to
call the nodeset() method of the target XObject the code then similarly
sigsegv's, I am rather confident that something about "theResult" is
unexpected. As this is down inside Xalan internal code, I would agree that it
is at least something which the Xalan code should guard against. However, I
will not be surprised if I learn that the reason this is occuring is due to
out-of-scoping issue or improper initialization issue which is miscoded by me
earlier in the ultimate parent object's lifetime.
As for parseSource, yes, it is trivial, isn't it? And pleasantly so. I went
ahead and recoded the xml string parsers to use that approach and it all
works nicely. So, I can get rid of all the parserLiaison stuff which isn't
necessary (for this use case anyway.)
I will strive to get a test case and enter a jira bug...
On Thursday 16 June 2005 12:38 pm, david_n_bertoni@us.ibm.com wrote:
> > No, I can't share those because they are highly proprietary. But, they
>
> are
>
> > actually irrelevant to conceptual work to be done. Which I can discuss.
>
> But surely you can come up with a trivial test case that reproduces the
> bug?
>
> > 1. That XPath::executeMore not return a null nodeset() or, at least,
>
> that
>
> > XPathEvaluator::selectNodeList not try to nodeset() on a *XObjectPtr
>
> which
>
> > isn't actually a NodeRefList.
>
> XPath::executeMore() is an internal routine, and you should not attempt to
> call it. If XPathEvaluator::selectNodeList() is using an XObjectPtr
> instance incorrectly, then that's a bug and we will fix it. Just create a
> Jira report, and attach a minimal set of input data, and some
> self-contained code that reproduces the problem.
>
> > 2. To have the XalanTransformer use its parseSource method to parse the
>
> input
>
> > XML once for both the XPath query and then for the transform() method
>
> (rather
>
> > than constructing a separate XalanDocument with the parserLiaison just
>
> for
>
> > the XPath evaluator) and then use the XalanTransformer to parse the
>
> reply XML
>
> > so that the post-transform XPath query can use that without having to
> > construct a new XalanDocument for the output string.
>
> This is trivial. Call XalanTransformer::parseSource(), which create an
> instance of XalanParsedSource for you. Then, you can call
> XalanParsedSource::getDocument() to get the underlying XalanDocument
> instance, which you can pass to any of the XPathEvaluator member
> functions.
>
> Dave
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xalan-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: XPathEvaluator sigsegv's on NodeRefList::operator=
Posted by da...@us.ibm.com.
> No, I can't share those because they are highly proprietary. But, they
are
> actually irrelevant to conceptual work to be done. Which I can discuss.
But surely you can come up with a trivial test case that reproduces the
bug?
> 1. That XPath::executeMore not return a null nodeset() or, at least,
that
> XPathEvaluator::selectNodeList not try to nodeset() on a *XObjectPtr
which
> isn't actually a NodeRefList.
XPath::executeMore() is an internal routine, and you should not attempt to
call it. If XPathEvaluator::selectNodeList() is using an XObjectPtr
instance incorrectly, then that's a bug and we will fix it. Just create a
Jira report, and attach a minimal set of input data, and some
self-contained code that reproduces the problem.
> 2. To have the XalanTransformer use its parseSource method to parse the
input
> XML once for both the XPath query and then for the transform() method
(rather
> than constructing a separate XalanDocument with the parserLiaison just
for
> the XPath evaluator) and then use the XalanTransformer to parse the
reply XML
> so that the post-transform XPath query can use that without having to
> construct a new XalanDocument for the output string.
This is trivial. Call XalanTransformer::parseSource(), which create an
instance of XalanParsedSource for you. Then, you can call
XalanParsedSource::getDocument() to get the underlying XalanDocument
instance, which you can pass to any of the XPathEvaluator member
functions.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: XPathEvaluator sigsegv's on NodeRefList::operator=
Posted by Lonnie VanZandt <lo...@ngc.com>.
No, I can't share those because they are highly proprietary. But, they are
actually irrelevant to conceptual work to be done. Which I can discuss.
I have distributed servers which pass XML strings as their messages. The
servers are mostly stateless and transform an input XML into an output XML
based on XSLT-scripted "business logic".
The transformer is humming along fine.
However, occassionally, a server needs to peek into an incoming XML request or
an outgoing XML reply in order to do content-specific processing above and
beyond what the XSLT can do (such as determining destinations and session
management).
So, rather than code up a mess of DOM traversal code, I need/want to ask an
XPathEvaluator to evaluate some "peeks" into the source and output XML
documents.
Therefore, a string of XML arrives on a socket, I parse the XML into a
XalanDocument, I (try to) peek into the request with XPathEvaluator, I get
any state I need, I set XSLT stylesheet parameters, I let XalanTransformer do
its transformation, I (try to) peek into reply with XPathEvaluator, I get any
state I need, and I send off the reply XML to the proper socket.
I have two wishes:
1. That XPath::executeMore not return a null nodeset() or, at least, that
XPathEvaluator::selectNodeList not try to nodeset() on a *XObjectPtr which
isn't actually a NodeRefList.
2. To have the XalanTransformer use its parseSource method to parse the input
XML once for both the XPath query and then for the transform() method (rather
than constructing a separate XalanDocument with the parserLiaison just for
the XPath evaluator) and then use the XalanTransformer to parse the reply XML
so that the post-transform XPath query can use that without having to
construct a new XalanDocument for the output string.
Makes sense?
On Thursday 16 June 2005 10:53 am, Axel Weiß wrote:
> Lonnie VanZandt wrote:
> > On a related note, I see that a XalanTransformer has a method to parse
> > - but not transform - an XML input into a XalanDocument. If so, and I
> > don't need a mutable DOM, and I already have a XalanTransformer
> > instance, then can't I use the "simpler" XalanTransformer::parseSource
> > method instead of the parserLiaison technique in the SimpleXPathAPI
> > and SerializeNodeSet sample examples?
>
> What is the intention of your doing? What are you trying to transform?
> Would you allow us to see your xsl and xml files?
>
> Axel
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: XPathEvaluator sigsegv's on NodeRefList::operator=
Posted by Axel Weiß <aw...@informatik.hu-berlin.de>.
Lonnie VanZandt wrote:
> On a related note, I see that a XalanTransformer has a method to parse
> - but not transform - an XML input into a XalanDocument. If so, and I
> don't need a mutable DOM, and I already have a XalanTransformer
> instance, then can't I use the "simpler" XalanTransformer::parseSource
> method instead of the parserLiaison technique in the SimpleXPathAPI
> and SerializeNodeSet sample examples?
What is the intention of your doing? What are you trying to transform?
Would you allow us to see your xsl and xml files?
Axel
--
Humboldt-Universität zu Berlin
Institut für Informatik
Signalverarbeitung und Mustererkennung
Dipl.-Inf. Axel Weiß
Rudower Chaussee 25
12489 Berlin-Adlershof
+49-30-2093-3050
** www.freesp.de **
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: XPathEvaluator sigsegv's on NodeRefList::operator=
Posted by Lonnie VanZandt <lo...@ngc.com>.
On a related note, I see that a XalanTransformer has a method to parse - but
not transform - an XML input into a XalanDocument. If so, and I don't need a
mutable DOM, and I already have a XalanTransformer instance, then can't I use
the "simpler" XalanTransformer::parseSource method instead of the
parserLiaison technique in the SimpleXPathAPI and SerializeNodeSet sample
examples?
On Thursday 16 June 2005 08:03 am, Lonnie VanZandt wrote:
> I was testing XObjectPtr::get() != NULL but this isn't the same result
> as !XObjectPtr::null(). If I use the latter, the test following the
> evaluate() call (for !null()) fails (the XObjectPtr _is_ null) and so the
> troublesome XObjectPtr->nodeset() call is avoided.
>
> But, why is evaluate returning a null XObjectPtr which selectNodeList is
> failing to check?
>
> On Thursday 16 June 2005 06:37 am, Lonnie VanZandt wrote:
> > Hmm, if I replace the selectNodeList call with a call to evaluate(), the
> > evaluate call succeeds without a crash. The XObjectPtr I get back has a
> > non-null get() value. However, if I try to convert that XObjectPtr to a
> > nodeset via thePtr->nodeset() (just as selectNodeList does) then,
> > immediately, the crash occurs. So, clearly, the XObjectPtr isn't pointing
> > to a valid NodeRefList nodeset - but, then, what is it pointing to?
> >
> > On Thursday 16 June 2005 06:12 am, Lonnie VanZandt wrote:
> > > Using some code very similar to the samples/SerializeNodeSet example, I
> > > currently get a core dump which shows that NodeRefList::operator= tried
> > > to dereference a null. (This is Xalan C++ 1.9).
> > >
> > > The preceding call to selectSingleNode returned a non-null contextNode
> > > for a non-null XalanDocument but the selectNodeList call which is given
> > > that contextNode and an empty (getLength=0) NodeRefList dumps core.
> > >
> > > I gather that the internal evaluate call is returning an XObjectPtr
> > > whose member pointer is 0. Then when operator= tries to copy
> > > theResult->nodeset() into the NodeRefList& which I pass in, the null
> > > derefence "fires".
> > >
> > > Now, it may be that there is a scoping or a memory manager issue which
> > > I've overlooked while reading the Xalan C++ API, sample code, and
> > > mailing lists.
> > >
> > > My XPathEvaluator, the NodeRefList, the source XalanDocument, and the
> > > context node all have greater, outer scope when selectNodeList gets
> > > called. Also, I can dereference the passed in NodeRefList& (via
> > > myNodeRefList.getLength()) safely immediately before the selectNodeList
> > > call within the same scope.
> > >
> > > Has this (likely pilot) error been encountered before?
> > >
> > > Perhaps my XalanDocument, constructed via the parserLiaison
> > > parseXMLStream method is somehow malformed? (The original source XML is
> > > assuredly well-formed because a peer XalanTransformer has no problems
> > > translating it from its original XSLTInputSource...)
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
> > > For additional commands, e-mail: xalan-dev-help@xml.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xalan-dev-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xalan-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: XPathEvaluator sigsegv's on NodeRefList::operator=
Posted by Lonnie VanZandt <lo...@ngc.com>.
I was testing XObjectPtr::get() != NULL but this isn't the same result
as !XObjectPtr::null(). If I use the latter, the test following the
evaluate() call (for !null()) fails (the XObjectPtr _is_ null) and so the
troublesome XObjectPtr->nodeset() call is avoided.
But, why is evaluate returning a null XObjectPtr which selectNodeList is
failing to check?
On Thursday 16 June 2005 06:37 am, Lonnie VanZandt wrote:
> Hmm, if I replace the selectNodeList call with a call to evaluate(), the
> evaluate call succeeds without a crash. The XObjectPtr I get back has a
> non-null get() value. However, if I try to convert that XObjectPtr to a
> nodeset via thePtr->nodeset() (just as selectNodeList does) then,
> immediately, the crash occurs. So, clearly, the XObjectPtr isn't pointing
> to a valid NodeRefList nodeset - but, then, what is it pointing to?
>
> On Thursday 16 June 2005 06:12 am, Lonnie VanZandt wrote:
> > Using some code very similar to the samples/SerializeNodeSet example, I
> > currently get a core dump which shows that NodeRefList::operator= tried
> > to dereference a null. (This is Xalan C++ 1.9).
> >
> > The preceding call to selectSingleNode returned a non-null contextNode
> > for a non-null XalanDocument but the selectNodeList call which is given
> > that contextNode and an empty (getLength=0) NodeRefList dumps core.
> >
> > I gather that the internal evaluate call is returning an XObjectPtr whose
> > member pointer is 0. Then when operator= tries to copy
> > theResult->nodeset() into the NodeRefList& which I pass in, the null
> > derefence "fires".
> >
> > Now, it may be that there is a scoping or a memory manager issue which
> > I've overlooked while reading the Xalan C++ API, sample code, and mailing
> > lists.
> >
> > My XPathEvaluator, the NodeRefList, the source XalanDocument, and the
> > context node all have greater, outer scope when selectNodeList gets
> > called. Also, I can dereference the passed in NodeRefList& (via
> > myNodeRefList.getLength()) safely immediately before the selectNodeList
> > call within the same scope.
> >
> > Has this (likely pilot) error been encountered before?
> >
> > Perhaps my XalanDocument, constructed via the parserLiaison
> > parseXMLStream method is somehow malformed? (The original source XML is
> > assuredly well-formed because a peer XalanTransformer has no problems
> > translating it from its original XSLTInputSource...)
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xalan-dev-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xalan-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: XPathEvaluator sigsegv's on NodeRefList::operator=
Posted by Lonnie VanZandt <lo...@ngc.com>.
Ah, a strong indicator of pilot error: there is (yet another)
XPathEvaluator::initialize() static method which I overlooked, forgot to
call, and is probably at least a source of potential problems if not this
actual problem.
On Thursday 16 June 2005 06:37 am, Lonnie VanZandt wrote:
> Hmm, if I replace the selectNodeList call with a call to evaluate(), the
> evaluate call succeeds without a crash. The XObjectPtr I get back has a
> non-null get() value. However, if I try to convert that XObjectPtr to a
> nodeset via thePtr->nodeset() (just as selectNodeList does) then,
> immediately, the crash occurs. So, clearly, the XObjectPtr isn't pointing
> to a valid NodeRefList nodeset - but, then, what is it pointing to?
>
> On Thursday 16 June 2005 06:12 am, Lonnie VanZandt wrote:
> > Using some code very similar to the samples/SerializeNodeSet example, I
> > currently get a core dump which shows that NodeRefList::operator= tried
> > to dereference a null. (This is Xalan C++ 1.9).
> >
> > The preceding call to selectSingleNode returned a non-null contextNode
> > for a non-null XalanDocument but the selectNodeList call which is given
> > that contextNode and an empty (getLength=0) NodeRefList dumps core.
> >
> > I gather that the internal evaluate call is returning an XObjectPtr whose
> > member pointer is 0. Then when operator= tries to copy
> > theResult->nodeset() into the NodeRefList& which I pass in, the null
> > derefence "fires".
> >
> > Now, it may be that there is a scoping or a memory manager issue which
> > I've overlooked while reading the Xalan C++ API, sample code, and mailing
> > lists.
> >
> > My XPathEvaluator, the NodeRefList, the source XalanDocument, and the
> > context node all have greater, outer scope when selectNodeList gets
> > called. Also, I can dereference the passed in NodeRefList& (via
> > myNodeRefList.getLength()) safely immediately before the selectNodeList
> > call within the same scope.
> >
> > Has this (likely pilot) error been encountered before?
> >
> > Perhaps my XalanDocument, constructed via the parserLiaison
> > parseXMLStream method is somehow malformed? (The original source XML is
> > assuredly well-formed because a peer XalanTransformer has no problems
> > translating it from its original XSLTInputSource...)
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xalan-dev-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xalan-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: XPathEvaluator sigsegv's on NodeRefList::operator=
Posted by Lonnie VanZandt <lo...@ngc.com>.
Hmm, if I replace the selectNodeList call with a call to evaluate(), the
evaluate call succeeds without a crash. The XObjectPtr I get back has a
non-null get() value. However, if I try to convert that XObjectPtr to a
nodeset via thePtr->nodeset() (just as selectNodeList does) then,
immediately, the crash occurs. So, clearly, the XObjectPtr isn't pointing to
a valid NodeRefList nodeset - but, then, what is it pointing to?
On Thursday 16 June 2005 06:12 am, Lonnie VanZandt wrote:
> Using some code very similar to the samples/SerializeNodeSet example, I
> currently get a core dump which shows that NodeRefList::operator= tried to
> dereference a null. (This is Xalan C++ 1.9).
>
> The preceding call to selectSingleNode returned a non-null contextNode for
> a non-null XalanDocument but the selectNodeList call which is given that
> contextNode and an empty (getLength=0) NodeRefList dumps core.
>
> I gather that the internal evaluate call is returning an XObjectPtr whose
> member pointer is 0. Then when operator= tries to copy theResult->nodeset()
> into the NodeRefList& which I pass in, the null derefence "fires".
>
> Now, it may be that there is a scoping or a memory manager issue which I've
> overlooked while reading the Xalan C++ API, sample code, and mailing lists.
>
> My XPathEvaluator, the NodeRefList, the source XalanDocument, and the
> context node all have greater, outer scope when selectNodeList gets called.
> Also, I can dereference the passed in NodeRefList& (via
> myNodeRefList.getLength()) safely immediately before the selectNodeList
> call within the same scope.
>
> Has this (likely pilot) error been encountered before?
>
> Perhaps my XalanDocument, constructed via the parserLiaison parseXMLStream
> method is somehow malformed? (The original source XML is assuredly
> well-formed because a peer XalanTransformer has no problems translating it
> from its original XSLTInputSource...)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xalan-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org