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"
<[EMAIL PROTECTED] To
usa.com> "Apache AXIS C Developers List"
<[email protected]>
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:[EMAIL PROTECTED]
Sent: Friday, May 13, 2005 6:48 PM
To: [email protected]
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/[EMAIL PROTECTED]
BMGB
To
[email protected]
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/[EMAIL PROTECTED]
MGB
To
[email protected]
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.
