[omniORB] debugging with omniORB

[Sai-Lai Lo]

>>>>> Stefan Seefeld writes:


> Well, yes. I dumped NP_RepositoryID() and got an 'invalid reference' or
> so. Well, that's exactly what I thought. However, I'd like to use RTTI
> to also get the object's type which's ref counter caused the exception.
> Therefor I added the necessary code to omniORB's objectRef.cc. I didn't
> have time to finish this so I'll try it tomorrow. The question remains:
> wouldn't it be possible to provide more verbose output from omniORB in
> the first place (something in the line of what I did), at least when
> -ORBtraceLevel is high enough ?

Sure, we can add the additional trace messages if it proves to be useful.  It
is a fine balance deciding what to trace. Too much output just make the
trace messages less useful and obscure the program logic in the source.

In the ORB runtime, there is quite a lot of defensive checks to detect if
the ORB internal state is becoming inconsistent. If that happens, the ORB
throws a fatalException with the processing. You can use
-ORBabortOnInternalError 1 to force a core dump when fatalException occurs
so at least you can do a post-mortem of what has gone wrong. By the way, a
fatalException does not necessarily mean that you have found a bug in the
ORB :-) May be 99 out of a 100 it is caused by bugs in the applications :-)

Sometimes I also remove the outer most try loop to just let the program to
core dump and see where an exception, a CORBA system exception for
instance, was raised. The difficult bit usually is to determine whether the
system exception originates from this address space or from the remote
address space. If the condition is reproducable, I usually just turn up the
trace level to 30 and see if the verbatum GIOP message dump gives any clue
as to the origin of the exception. I think it is possible to do better than
this. For instance, we can add a service context into the GIOP messages to
identify the address space where the exception originates. It may be
possible to use the minor code of a CORBA system exception to encode an
index into a table of execution points where CORBA system exceptions are
thrown. 

Any other suggestions on ways to make debugging easier are most welcomed.

Sai-Lai


-- 
Sai-Lai Lo                                   S.Lo@uk.research.att.com
AT&T Laboratories Cambridge           WWW:   http://www.uk.research.att.com 
24a Trumpington Street                Tel:   +44 1223 343000
Cambridge CB2 1QA                     Fax:   +44 1223 313542
ENGLAND