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