You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-users@xalan.apache.org by David Bertoni <db...@apache.org> on 2009/09/01 22:56:53 UTC

Re: Issues with Xalan on AIX

Albers, Michael wrote:
> Hello,
>  
> I've been trying to use Xalan on an AIX machine and have run into some 
> problems. I've been using the exact same code and XML on a Solaris 
> platform with no issues. Despite my best efforts in tweaking my code and 
> looking through forums I haven't been able to solve my AIX woes.
>  
> I've been experiencing three problems, detailed below.
>  
> 1. XPathEvaluator::terminate is causing my application to core. I've 
> traced this to a pure virtual function, XalanList::allocate, being 
> called by the memory manager instance. This but isn't much of an issue 
> as I'm implementing a wrapper class which will be the exclusive means 
> for other code to use the Xalan API. To do the initialization and 
> termination I created a singleton static subclass. The Xalan/Xerces 
> initialization is done in the constructor and the termination, in the 
> destructor. This way the compiler does most of the work and the user's 
> of my code need not worry about initialization. Since the termination 
> will be done on process termination actually terminating Xalan doesn't 
> seem to be much of an issue.
This usually occurs because of order-of-destruction issues.  Please 
verify you have no existing Xalan-C objects before your static singleton 
class is destroyed.

You're probably seeing a difference in behavior on the two platforms 
because the order of destruction of static objects is not specified 
between compilation units. It's very difficult if not impossible to get 
this to work right, because each platform is different.

AIX does have a notion of destructor priorities for shared objects, so 
you may want to exploit this feature to ensure the shared object 
initialization and destruction sequence works between the Xalan-C and 
Xerces-C libraries, and a higher priority than other shared objects that 
depend on yours. This can be tricky to do, so you may need to abandon 
your dependency on a static singleton object. This will also allow 
better error-handling, since you will be unable to gracefully handle 
errors initializing the Xerces-C and Xalan-C libraries

>  
> 2. XPaths won't evaluate when using namespaces in the XML. My code is 
> heavily based off of the SimpleXPathAPI sample. When I run 
> SimpleXPathAPI with my XML (with namespaces) the data is retrieved 
> correctly. When I use the exact same XPath with my code no results are 
> returned. I've made sure that the XML is valid and the XPath is 
> syntactically correct.
This usually occurs because you're not providing an appropriate 
PrefixResolver instance to resolve the namespace prefixes in the 
document.  You can search the archives of the mailing list for the 
string "PrefixResolver" to see more Xalan-specific details for dealing 
with this.

> 3. In my efforts to fix number two I tried removing the namespace from 
> my XML. That worked somewhat better but now my application cores later 
> on down the line. After retrieving about half of the data from the XML 
> the core happens. I've tracked this down to another pure virtual 
> function being called. This time the call happens in 
> XalanReferenceCountedObject::removeReference.
You will need to provide a stack trace at a minimum, but I suspect if 
your code works on other platforms, but doesn't on AIX, there are 
compiler issues getting in the way.

One common cause of this is not obeying the rules of the XPathEvaluator 
APIs.  For example, the evaluate() member functions that return 
XObjectPtr instances make it explicit you cannot call any of the 
evaluate() member functions again while the returned object is still in 
scope. For example, this pseudo-code can cause the error you're seeing:

     const XObjectPtr    theResult1(
         theEvaluator.evaluate(
             theDOMSupport,
             theContextNode,
             XPath1.c_str(),
             thePrefixResolver));

     const XObjectPtr    theResult2(
         theEvaluator.evaluate(
             theDOMSupport,
             theContextNode,
             XPath2.c_str(),
             thePrefixResolver));

Since XObjectPtr is a smart-pointer to an implementation class, making a 
  copy of the returned XObjectPtr won't work.  Instead, you'll need to 
make a copy of the underlying data.  See the post for more info:

http://marc.info/?l=xalan-c-users&m=123615175207902&w=2

I would suggest you build a debug version of the library on AIX, which 
will enable run-time assertions, which may help you catch problems of 
this nature sooner.

> For what it's worth here's some various version information.
>  
> Xalan: 1.10
> Xerces: 2.7
> AIX: 6.1 TL2 SP2
> xlC_r 09.00.0000.0006
Xalan-C hasn't been built regularly on AIX since xlC 6.0, and I have no 
access to an AIX machine much less the AIX compiler, so it's unlikely I 
can offer too much assistance.

Dave