axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Hawkins <HAWKI...@uk.ibm.com>
Subject Re: Fw: FFDC (2)
Date Mon, 23 May 2005 07:14:37 GMT
FFDC should "just work" irrespective of server or client (I hope!)

Maybe we could get the trace tool to add in toString() on all classes that 
don't have one it doesn't override it !

1.7 probably according to my plan - but Mark has a habit of pulling these 
things out of the bag :-)





Samisa Abeysinghe <samisa.abeysinghe@gmail.com> 
21/05/2005 11:10
Please respond to
"Apache AXIS C Developers List"


To
Apache AXIS C Developers List <axis-c-dev@ws.apache.org>
cc

Subject
Re: Fw: FFDC (2)






If we could get a generic FFDC, which can be used both on client as
well as server, it would help a great deal on server side as well.

Additionally, if we could get, may be the trace tool to generate
toString() for classes that we have that will be great. I persanlly
preffer a human readable sting output here because that is much easier
in debugging.

Are we looking to implement this in 1.6? I think given the time lines,
it is quite possible to ship this with 1.6

Thanks,
Samisa...

On 5/16/05, Mark Whitlock <mark_whitlock@uk.ibm.com> wrote:
> 
> 
> 
> 
> Hi Samisa,
> Axis could register a signal handler that would dump out to file various
> (all?) Axis objects. On Windows, it's possible to ask for a minidump.
> Applications can register their own signal handlers, and these can be
> chained together. It would then be the responsibility of the application 
to
> ensure signal handlers are chained in the correct order. I'm not sure
> whether signal handlers are platform dependent or not.
> 
> Axis' signal handler might just hex dump all objects on the object stack
> (see John's note). Or it could call toString() methods on these objects, 
if
> we produced toString() methods, either by writing them by hand, or
> generating them during the build using the trace tool.
> 
> There is no standard C++ API to do FFDC. I know of code that provides an
> FFDC API. I need to investigate whether it does what we want and whether 
it
> could be donated to or used by Apache. If that is not possible, we could
> write our own implementation of FFDC. Basically it is providing signal
> handlers and an API to FFDC at suitable points in the code. The FFDC 
would
> then write out diagnostic information to a file.
> 
> By "FFDC at suitable points in the code" I mean FFDC in a situation that
> should be impossible to get to or if something becomes seriously 
corrupted.
> An FFDC can be an excellent place to start debugging a problem - often 
the
> most useful information is the file and line number of the FFDC that was
> called, and a knowlege of what was being attempted at the time.
> Mark
> Mark Whitlock
> IBM
> 
> ----- Forwarded by Mark Whitlock/UK/IBM on 16/05/2005 14:14 -----
> 
>             "Samisa
>             Abeysinghe"
>             <SAbeysinghe@virt To
>             usa.com>                  "Apache AXIS C Developers List"
>                                       <axis-c-dev@ws.apache.org>
>             16/05/2005 04:57 cc
> 
> Subject
>             Please respond to         RE: FFDC (2)
>              "Apache AXIS C
>             Developers List"
> 
> 
> 
> 
> 
> 
> 
> 
> I too am new to FFDC. Thanks to Mark for clarifications.
> 
> So as far as I understand, if we do not do FFDC with every exception,
> which I too think is a bad idea, it seems to me that we have to have
> some 'monitor' or 'handler' kind of things to identify and capture the
> signals that we want - like SIGSEGV as Mark has suggested. Is my
> understanding correct here? If I am correct, then we may be talking
> about a signal capturing mechanism, which is platform dependent. The
> other question I have is, how do we attach the toString invocation
> through this?
> 
> Do we have to implement this using the basic C++ API, or do we have
> libraries to do this?
> 
> Thanks,
> Samisa...
> 
> -----Original Message-----
> From: Mark Whitlock [mailto:mark_whitlock@uk.ibm.com]
> Sent: Friday, May 13, 2005 6:48 PM
> To: axis-c-dev@ws.apache.org
> Subject: Fw: FFDC (2)
> 
> 
> 
> 
> 
> If we required toString() methods in our classes, then the existing
> trace
> tool could generate these toString() methods during the build, since it
> already parses class definitions and recognises fields within them.
> Mark
> Mark Whitlock
> IBM
> 
> ----- Forwarded by Mark Whitlock/UK/IBM on 13/05/2005 13:41 -----
> 
> 
>             Mark
> 
>             Whitlock/UK/IBM@I
> 
>             BMGB
> To
>                                       axis-c-dev@ws.apache.org
> 
>             13/05/2005 13:39
> cc
> 
> 
> 
> Subject
>             Please respond to         Fw: FFDC
> 
>              "Apache AXIS C
> 
>             Developers List"
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Hi,
> I think FFDC should be used to show bugs in Axis C++ not application
> errors. Places where I'd like to see FFDC are the default case in switch
> statements and where a pointer is unexpectedly null. If we FFDC on all
> exceptions, then most FFDCs will be showing simple application errors or
> user errors which are already properly reported back to the application
> in
> the exception data. I'd really like to see FFDC where we fail to
> allocate
> storage (a "new" fails) or if we get a SIGSEGV in Axis code.
> 
> How will the FFDC handler know how to dump objects in the object stack
> out
> to a file? I guess it will need a toString() method on various classes.
> In
> which case the only objects that ever need to be on the object stack are
> the Stub and Call objects, since all other objects are referenced
> (directly
> or indirectly) from Call and Stub. So Call.toString() could call
> ClientAxisEngine.toString(), ..., etc, which in turn would call the
> toString() method on all other objects.
> Mark
> Mark Whitlock
> IBM
> 
> ----- Forwarded by Mark Whitlock/UK/IBM on 13/05/2005 13:22 -----
> 
>             John
>             Hawkins/UK/IBM@IB
>             MGB
> To
>                                       axis-c-dev@ws.apache.org
>             13/05/2005 11:52
> cc
> 
> 
> Subject
>             Please respond to         FFDC
>              "Apache AXIS C
>             Developers List"
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Hi Folks,
> 
> time to discuss FFDC again :-)
> 
> We'd really like to see FFDC being used in the code. Here are some
> thoughts....
> 
> FFDC is meant to be used in areas where the exception was completely
> unexpected. In WebSphere application server FFDC consists of two
> elements.
> 
> 1.        The Object Stack
> is a list of "useful things to have" so that when an FFDC situation
> occurs
> the FFDC handler has some information as to what state objects were in
> prior to the Failure. This system is only as good as the information
> given
> put on the stack and relies on developers putting the appropriate
> objects
> to the stack.
> 
> 2.        FFDC at every exception
> Websphere application server originally expected every exception to have
> an
> FFDC record output. This led to situations where FFDC was being produced
> and the exception was being thrown back up the stack. The next catcher
> would then produce more FFDC. This is obviously not a good system.
> 
> 
> I don't believe that it's possible to automate the putting in of FFDC
> and
> that it's a completely manual process - thoughts?
> 
> 
> Does everyone agree that we should have the Object stack or do we just
> want
> an FFDC API only? I think the Object stack would be a good idea in
> certain
> circumstances - it does require that you know the code-paths (and there
> respective entry points). However, we really only have a couple of these
> paths so it should be fairly obvious?
> 
> Does anyone have any thoughts on the API?
> 
> thoughts please?
> 
> 
> cheers,
> John.
> 
>


Mime
View raw message