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