AW: [omniORB] Exception during bindObjectToName

[Hennig Andreas]

Sorry, I might not have been clear enough last time round. I'm NOT trying to
put CORBA stuff into a DLL.  I've already got a DLL that provides some basic
functionality, which should be made available via CORBA (after some
processing, which happens in the CORBA classes).

When I try to register this resulting CORBA server, I get the exception.

Thanks for the last mail, we might need that somewhere else.

Andreas Hennig
... the usual disclaimer: opinions/statements are mine, not my
employer's - that particularly applied to jokes ...


>>>>> Andreas Hennig writes:

> Hi everybody, I've got a problem ...
> Config:
>  OmniORB 2.6 (i.e. 2.5+snapshot_980827_x86_win32) (2.5 had same problem)

>  WinNT 4.0

> System:
>  we have a DLL, which - in order to get a handle that seems to be
> necessary - is hosted by a simple Win GUI application. The CORBA server
> uses this DLL, so we packed it into the WIN Appl, started by a special
> button and the GUI, which calls a function (almost) identiacal to main
> in the examples.

> Problem:
>  All's fine until we try to bind the object to a name (bindObjectToName
> in the examples).
> in the statement
>  try {
>       // Bind the context to root, and assign testContext to it:
>       testContext = rootContext->bind_new_context(contextName);
>     }
> sometimes also a little later in
>     // Bind obj with name Echo to the testContext:
>     try {
testContext-> bind(objectName,obj);
>     }
> an exception is thrown:
> First-chance exception in Agent.exe (OMNIORB260_RT.DLL): 0xC0000005:
> Access Violation.
> First-chance exception in Agent.exe (KERNEL32.DLL): 0xE06D7363:
> Microsoft C++ Exception.

> We think, the reason for this is probably a bug somewhere deep in a
> DLL.  We thought the windows event-loop might interfere with the CORBA
> listening, so we put them into different threads, no result.

> Question:
>  Did anyone have a similar problem and maybe even managed to solve it?
>  I don't particularly like the idea of the GUI hanging around just to
> make windows/the DLL insisting on a handle happy - any suggestions (or
> statements of sympathy)?
>... the usual disclaimer: opinions/statements are mine, not my
>employer's - that particularly applied to jokes ...