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