Re: Deadlock?

[Havoc Pennington <hp redhat com>]

Darin Adler <darin eazel com> writes:
> I am starting Nautilus and it hangs.
> 
> I find that it is waiting for a reply for the CORBA call
> ConfigServer_add_client. I assume the ConfigServer in question is an object
> whose server is the gconfd process.
> 
> So I fire up gdb and attach to gconfd to see what the daemon is doing. It is
> waiting for an outgoing connection to do a ConfigListener_update_listener
> outgoing CORBA call. I'm guessing that the listener is an object whose
> server is the nautilus process.
> 
> This seems like a classic case of deadlock to me. But I'm assuming that
> GConf is designed to avoid such problems and some other bug is leading to
> this problem.
> 
> Can you help me Havoc?

update_listener is oneway. My understanding is that this means the
call isn't supposed to block waiting on the client, so there shouldn't
be a deadlock. So that's what's supposed to happen. 

If the bug is in my understanding of oneway, we are fairly well
screwed; otherwise it's probably just some ORBit glitch.
 
> PS: The problem I was reporting last week does seem to be two gconfd
> processes running at once. I suspect a problem with oafd, but I can't
> reproduce the problem easier nor can I spot the flaw in oafd code.
> 

oafd is supposed to maintain the uniqueness of the gconfd process:

  result = oaf_active_server_register(IID, server);

  if (result != OAF_REG_SUCCESS)
    {
      switch (result)
        {
        case OAF_REG_NOT_LISTED:
          gconf_log(GCL_ERR, _("OAF doesn't know about our IID; indicates broken installation; can't register; exiting\n"));
          break;
          
        case OAF_REG_ALREADY_ACTIVE:
          gconf_log(GCL_ERR, _("Another gconfd already registered with OAF; exiting\n"));
          break;

        case OAF_REG_ERROR:
        default:
          gconf_log(GCL_ERR, _("Unknown error registering gconfd with OAF; exiting\n"));
          break;
        }

Perhaps there's a race of some kind...

Havoc