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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
