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: [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]
