Vivien Malerba wrote: > On Sat, Mar 22, 2008 at 10:58 PM, Mark Johnson <[EMAIL PROTECTED]> wrote: > >> Vivien Malerba wrote: >> >> > >> >> I don't think I have 2 references to the connection. I've attached a >> >> current snapshot of my file to let you see it. It's a work in progress >> >> for a test case for one of my bugs. >> >> >> > >> > The problem comes from the fact that when you call >> > g_object_unref(pConn), there is still an object holding a reference on >> > the pConn object, it is the GdaDataModel returned from the >> > gda_connection_statement_execute_select() function (which you ignore >> > in your example but still exists). Here is attached your example, >> > modified to show the reference count on the pConn object. >> > >> > Cheers, >> > >> > Vivien >> > >> Thanks, that fixed it. The g_object_unref now does close the >> connection, so no unexpected EOF in the PostgreSQL log. >> >> This is something I find difficult in glib/gnome programming in general >> - how to know when something needs to be unref'ed, and when something >> else might be keeping a reference to your object. For example, nothing >> in the gda_connection_statement_execute or >> gda_connection_statement_execute_select documentation indicates that the >> connection reference count will be incremented. The GdaDataModel page >> does not even contain the word connection. >> > > The idea is that for any function which creates a new object, then you > need to call g_object_unref() on the object, This much is obvious. > otherwise you must > consider that the returned object is valid only within your function > body (and if you wat to keep it, call g_object_ref() and > g_object_unref() when done with it). > Wouldn't this cause a memory leak? Wouldn't I have to destroy the object by calling g_object_unref on it? > The reason the GdaDataModel keeps a reference on the connection is > that some implementations need to execute some queries when they are > used (like for cursor based access and for the soon-to-come dete model > modification). > This makes sense, but is not documented. I had wrongly assumed that the connection was only needed for the duration of that function's execution.
My complaint is that I can't tell from a function's prototype whether it needs the object only for the duration of that function's execution, or if the object needs to keep a reference to my passed-in object. > Don't hesitate to signal any part of the doc you find misleading or > unclear about that point. > Any function that changes a reference count should be documented as doing so. Here's another example of my complaint from the gobject documentation (gobject/ch02.html) regarding g_value_copy: "...the exact semantic of the copy calls is undefined since they depend on the implementation of the copy function. Certain copy functions might decide to allocate a new chunk of memory and then to copy the data from the source to the destination. Others might want to simply increment the reference count of the instance and copy the reference to the new GValue." Each object defines its own copy semantics. Fair enough. The onus is now on each object to document its copy semantics. They don't (for anything I've looked at; not just libgda). This makes writing non-leaky code much more difficult. > Cheers, > > Vivien > > Hopefully, this doesn't sound too much like I'm ranting about it. I intend it as constructive criticism. Mark _______________________________________________ gnome-db-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-db-list
