[omniORB] OmniORB 3.0.4 omniNames problem with Solaris 8/x86 MU4 and GCC 3.0

[Fazal Majid]

Registering a server such as echo/eg3_impl in omniNames seems to deadlock
both omniNames and the server.

The first time the server is started, it creates test.my_context and
everything works fine. But if you restart it (and thus do not
bind_new_context test.my_context but instead resolve it), it hangs both the
server and omniNames, as well as any Naming client such as nameclt.
Apparently the hanging occurs when calling Naming_Context::resolve on the
root naming context to resolve test.my_context.

It seems from a cursory analysis with GDB that both the server and omniNames
are waiting for one another, and mutexes are locked in omniNames that do not
allow other naming clients to do anything.

I am using a 3.0.3/gcc-2.95.2 omniNames as a workaround. The problem does
not occur with the omniORB 3.0.4 when compiled with GCC 2.95.2 either. We
have written a custom load-balancing name server implementation in Python,
and that works fine also, even when implemented on omniORB 3.0.4/omniORBpy
1.4 both compiled with GCC 3.0. Thus, it is highly likely the problem is in
the interaction between omniNames and GCC 3.0 on Solaris 8/x86.

I can recompile all of omniORB 3.0.4 with -g and jump in with GDB, but I'm
not sure what to look for. Any help would be greatly appreciated.

Yours,

--
Fazal Majid                          Chief Technology Officer
fmajid@kefta.com                     Kefta
Voice: +1 415 391 6881 ext 8014      153 Kearny St. Suite 209
Fax: +1 415 391 7097                 San Francisco, CA 94108, USA