axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bartley <tbart...@au1.ibm.com>
Subject Re: Fw: HTTPTransportException
Date Fri, 11 Mar 2005 07:25:46 GMT
Hi Mark,

That wasn't the (only) problem. Eventually I tracked it down. It's because 
the shared libraries are not loaded with the RTLD_GLOBAL flag. Because of 
this the type definition of the exception thrown in the channel library is 
considered different to the type definition (of the same class) in the 
transport library. This causes flushOutput to generate a call to the 
unhandled exception handler because it's not considered a matching 
exception. The fix is to add RTLD_GLOBAL to the flags passed to dlopen as 
defined in PlatformSpecificUnix.hpp. See http://gcc.gnu.org/faq.html#dso 
for details as to why this is necessary.

Incidentally HTTPTransport::flushOutput is incorrectly declared. It has 
code that throws (well, rethrows) AxisExceptions but it is declared to 
only throw HTTPTransportExceptions. (Re)Throwing an AxisException should 
result in the C++ "unexpected()" being called which will abort the process 
by default. That is, any code that does:

class BaseE {};
class SubE : public BaseE {};

void f() throw(SubE)
{
        throw BaseE();
}

int main()
{
        try {
                f();
        }
        catch (SubE& e) {
                cout << "Caught sub" << endl;
        }
        catch (BaseE&e ) {
                cout << "Caught base" << endl;
        }
}

should, according to the C++ spec, abort. f should be declared 
throw(BaseE) and then it can throw either BaseE's or SubE's and callers 
can catch either.

Cheers,

Tim
--
IBM Tivoli Access Manager Development
Gold Coast Development Lab, Australia
+61-7-5552-4001 phone
+61-7-5571-0420 fax



Mark Whitlock <mark_whitlock@uk.ibm.com> 
09/03/2005 20:26
Please respond to
"Apache AXIS C User List"


To
axis-c-user@ws.apache.org
cc

Subject
Fw: HTTPTransportException










Hi Tim,
There was a problem in this area that I fixed on 22/02/05 to
ClientAxisEngine::process. AxisException is an abstract class so it has to
have some implementation class extending it. The transport library is
unloaded before the client application catches any exception.
HTTPTransportException is in the transport library. This caused a sigsegv.
I fixed this in ClientAxisEngine::process by converting the
HTTPTransportException to an AxisGenException (which is in the AxisClient
library so never gets unloaded).

Please confirm that you are picking up my fix. If you still see the
problem, please reproduce it with trace on, and send the trace so I can
investigate it further.
Thanks,
Mark
Mark Whitlock
IBM

----- Forwarded by Mark Whitlock/UK/IBM on 09/03/2005 10:11 -----
 
             Tim Bartley 
             <tbartley@au1.ibm 
             .com>                                                      To 

                                       axis-c-user@ws.apache.org 
             09/03/2005 05:20                                           cc 

 
                                                                   Subject 

             Please respond to         HTTPTransportException 
              "Apache AXIS C 
                User List" 
 
 
 
 





Hi,

I have a client application on Suse Linux Enterprise 8.1 (Service Pack 3) 
-
a g++ 3.2.2/glibc 2.2 environment. I have built axis and it's dependents 
in
this environment.

When an HTTPTransportException is generated, client calling code is not
able to catch the exception - at least not in this environment even though
I have:

try {
        stub->invoke()
}
catch (AxisException& e)
{
        printf("AxisException: %s\n", e.what());
}

the HTTPTransportException is not caught.

I'm not sure where the bug is. Is it because my client code can see no
declaration or definition of HTTPTransportException and therefore when my
code is compiled it has no way of knowing that HTTPTransportException is a
sub-class of AxisException in which case this could be an Axis C++ bug
(only AxisExceptions should be propagated - not their sub-classes) or a
compiler bug. Or is this a linker or C++ runtime bug such that when the
stack is unwound it should be known that the thrown HTTPTransportException
matches my catch statement.

Is anyone else seeing this behaviour? Is anyone else seeing
HTTPTransportException's successfully caught by client code at all? On
Linux? On other platforms?

Thanks,

Tim
--
IBM Tivoli Access Manager Development
Gold Coast Development Lab, Australia
+61-7-5552-4001 phone
+61-7-5571-0420 fax



Mime
View raw message