[omniORB] Crash on using nil reference

Duncan Grisby dgrisby@uk.research.att.com
Fri, 04 May 2001 17:05:33 +0100


On Friday 4 May, "Tim Ward" wrote:

> Thought: I'm using Visual C++ version 5 (for historical reasons) - should
> the delivered libraries and DLLs work with version 5, or would I be better
> advised to use version 6?

Our binaries should work with VC 5, as long as it has the latest
patches. VC 5 without the patches dies at the linking stage (with the
lovely message "corrupted file or disk full"). You've clearly got past
that, so I would have thought you'd be OK. If you have VC 6 available,
it might be worth trying that.

> >Do the echo examples run?  What happens if you run
> >eg3_clt having put a nil object reference in the naming service?
> 
> I haven't tried running the examples. My task is to evaluate OmniORB as a
> replacement for Visibroker, so I'm emulating and converting bits of
> (working) Visibroker code.

It's worth trying the examples if you can't get your application
going. They're the simplest possible programs, so they are a good
check to see if anything is working at all.

> (When/if I've got this crashing sorted the next question will be how to
> integrate the orb's loop with MFC, so that an application can be both an MFC
> app with a user interface and a CORBA server, like the Visibroker WDispatch
> stuff (*without* any busy-waiting loops) - I'm sure this is a FAQ, I just
> haven't found the documentation yet.)

Depending on exactly what you're trying to do, you either have to do
nothing at all, or you have a bit of a problem here. omniORB always
uses its own threads to dispatch incoming requests, so you can't hook
its event loop up to anything else. It means you can block your main
thread in the MFC event loop, and calls will still be dispatched. The
problem would occur if you have to access MFC things from the thread
which is doing the MFC event loop. In that case, you would have to do
your own thread switching during calls.

Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --