Vivien Malerba wrote:
On Sat, Mar 22, 2008 at 10:58 PM, Mark Johnson <mrj001 shaw ca> 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.
Wouldn't this cause a memory leak? Wouldn't I have to destroy the object by calling g_object_unref on it?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).
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.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).
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.
Any function that changes a reference count should be documented as doing so.Don't hesitate to signal any part of the doc you find misleading or unclear about that point.
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.
Hopefully, this doesn't sound too much like I'm ranting about it. I intend it as constructive criticism.Cheers, Vivien
Mark