[omniORB] Oddities in debugging OmniOrb programs

[Ted McFadden]

On Wed, 24 Feb 1999, Judy Anderson wrote:
> ......
> Interestingly, when I got to the uninitialized memory access, and
> clicked "step over", a little pop-up with "thread has exited"
> appeared.  This has happened before: when I do something wrong in my
> program, I would normally expect it to fall over with the usual
> Microsoft "clicked okay to exit, cancel to debug" pop-up, but instead...


A few things I have tried when working with NT that may be of use to you:

  You can set the VC debugger to catch unhandled exceptions. The menu
  option appears under the Build menu once you start debugging (if I
  remember correctly). In practice, this can be a bit tedious, but
  it will work. 

> when I am running at an OmniOrb program, the thread that is servicing
> the client request simply exits, and the client receives a
> communication failure exception.....

  If there's a chance an operation in a thread might throw an unhandled
  C++ exception (or a WIN32 SE Exception, ACCESS_VIOLATION,FPE errors...)
  its useful to have a try/catch(...) around the operation to prevent
  unexpected behavior. catch(...) catches unhandled SE exceptions. 

  (On NT, _set_se_handler can be used to get first crack at SE exceptions
  such as ACCESS_VIOLATION or FPE errors and map them to a C++
  exception of your choice. This can be useful if only to print things
  like "Thread X: ACCESS_VIOLATION" to an error log before continuing. By
  default, a standard C++ catch(...) will catch any SEs. 

  Do not use any of the older C/C++ SEH handling extensions/macros. Only 
  use _set_se_handler to convert SEs to proper C++ exceptions.
  )


Cheers,

Ted.

-- 
Ted McFadden   
http://www.dstc.edu.au/BDU/staff/ted-mcfadden.html
DSTC Level 7, GPS Building 78, Staff House Road 
The University of Queensland St Lucia 4072 +61 7 3365-4310