Hook more g_object_new_xxx function to prevent missing some GObjects tracking #6
Conversation
… to prevent missed objects
CCob
changed the title
|
Nice work, I merged it to my repo on top #8, https://github.com/Lekensteyn/gobject-list/tree/trace-callstack-w-pr6. Some objects were tracked correctly, but there is one remaining case. Either something is not tracked, or GCredentials is really being strange. See item 30 at https://lekensteyn.nl/gobject-list-upower.html#30 |
|
Is this your own code using GCredentials or are you checking a different application? If the later, I wonder if the reference count has been decremented manually instead of using g_object_unref causing a negative reference? |
|
The application is not using GCredentials directly, it is probably the GDBus library. It would be very strange if an application touches the struct directly. |
| @@ -328,59 +328,96 @@ _object_finalized (gpointer data, | |||
| G_UNLOCK (gobject_list); | |||
| } | |||
|
|
|||
| static void | |||
| _track_object(GObject* obj) | |||
There was a problem hiding this comment.
As evil as it sounds... I would consider making this a macro so that it doesn't turn up into your tracebacks.
There was a problem hiding this comment.
What is wrong with this showing in the traces? I would prefer an inline function over a macro if that also solves the problem.
There was a problem hiding this comment.
It's a frame that's not useful in your trace. Inline works too. My C is rusty, I forgot inline was a thing :-P
g_object_new doesn't seem to be the lowest entry point to creating a GObject types. It seems to g_object_new -> g_object_new_valist -> g_object_newv, so this pull request hooks g_object_newv instead.
using LD_PRELOAD on gst-launch-0.10 I can confirm there are now much more objects being tracked.