Out of Memory Error and pending != NULL

[John (J5) Palmieri]

On Tue, 2006-09-19 at 11:55 -0500, keith preston wrote:
> Ok, so I have been developing some dbus utility services and have run
> into some errors I find difficult to debug.  I am using the glib
> bindings and I infrequently run into the following two errors
> 
> ** ERROR ** out of memory 
> 
> ** ERROR **: file dbus-gproxy.c: line 2123 .... assertation failed
> pending != NULL
> 
> 
> I can reproduce them with a little regularity.   Like if I bind my
> dbus call to the spacebar and just hit the spacebar 6 or 7 times after
> I launch my program, the pending !=null will always come up.  A few
> note from looking at the code 
> 
> ** ERROR ** out of memory
> This seems to be printed out in dbus_g_proxy_begin_call_internal as
> almost a generic message.   If we can't make the message this seems
> like a valid error, but if dbus_connection_send_with_reply fails,
> could there be another case that the error is not cause by memory?   I
> am pretty sure I am not running out of memory. 
> 
> ** ERROR **: file dbus-gproxy.c: line 2123 .... assertation failed
> pending != NULL
> From the note on dbus_connection_send_with_reply, it seems to imply
> that this will only be NULL is the connection is disconnected.  Are
> there any conditions where the connection can get interrupted? 
> 
> I can't believe that these are dbus bugs, but rather that I am not
> using dbus correctly.   Are there any common situation where these
> error might appear?    Here are a few abnormal things I am doing
> 
> Threading... can you make dbus call from any thread?  sync and async
> calls? 

Make sure you initialize threading with dbus_g_threads_init()

> Two way service....  I have two xml specifications that work together
> but are seperate services (myservice_server , myservice_client)  also
> I do have one case where both of these services exist in the same
> process (Glib Main Loop)    I already figured out that you can't to
> syncronous call this way, but this makes sense.  Anyway any hint on
> how I can resolve these issues would be appreciated. 

You need to be careful as without recursive locks D-Bus is not
re-entrant (it is not really re-entrant with recursive locks either but
the recursive locks will alleviate some deadlocks).  We don't recommend
calling into the same process.  In the future the bindings should be
able to detect if you are calling into the same process (to some degree)
and short circuit the call so it does not go over the bus.  Qt4 bindings
already do this.
 
-- 
John (J5) Palmieri <johnp at redhat.com>