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