New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Objects inheriting from objects that inherit from GLib.Opaque are unrefing their handle twice. #54
Comments
ylatuya
added a commit
to ylatuya/GtkSharp
that referenced
this issue
Jul 2, 2021
There was one finalizer being for level of inheritance. For example Gst.Message -> Gst.MiniObject -> GLib.Opaque ends with 2 finalizers being called, one calling gst_mini_object_unreg another one calling gst_message_unref The following implementation will only call once the unref function for the highest class in the hierarchy Fixes GLibSharp#54
ylatuya
added a commit
to ylatuya/GtkSharp
that referenced
this issue
Jul 2, 2021
There was one finalizer being for level of inheritance. For example Gst.Message -> Gst.MiniObject -> GLib.Opaque ends with 2 finalizers being called, one calling gst_mini_object_unreg another one calling gst_message_unref The following implementation will only call once the unref function for the highest class in the hierarchy Fixes GLibSharp#54
ylatuya
added a commit
to ylatuya/GtkSharp
that referenced
this issue
Jul 2, 2021
There was one finalizer being called for each level of inheritance. For example Gst.Message -> Gst.MiniObject -> GLib.Opaque ends with 2 finalizers being called, one calling gst_mini_object_unref and another one calling gst_message_unref The following implementation will only call once the unref function for the highest class in the hierarchy Fixes GLibSharp#54
ylatuya
added a commit
to ylatuya/GtkSharp
that referenced
this issue
Jul 5, 2021
There was one finalizer being called for each level of inheritance. For example Gst.Message -> Gst.MiniObject -> GLib.Opaque ends with 2 finalizers being called, one calling gst_mini_object_unref and another one calling gst_message_unref The following implementation will only call once the unref function for the highest class in the hierarchy Fixes GLibSharp#54
ylatuya
added a commit
to ylatuya/GtkSharp
that referenced
this issue
Jul 6, 2021
There was one finalizer being called for each level of inheritance. For example Gst.Message -> Gst.MiniObject -> GLib.Opaque ends with 2 finalizers being called, one calling gst_mini_object_unref and another one calling gst_message_unref The following implementation will only call once the unref function for the highest class in the hierarchy Fixes GLibSharp#54
ylatuya
added a commit
to LongoMatch/GtkSharp
that referenced
this issue
Jul 8, 2021
There was one finalizer being called for each level of inheritance. For example Gst.Message -> Gst.MiniObject -> GLib.Opaque ends with 2 finalizers being called, one calling gst_mini_object_unref and another one calling gst_message_unref The following implementation will only call once the unref function for the highest class in the hierarchy Fixes GLibSharp#54
thiblahute
pushed a commit
that referenced
this issue
Jul 29, 2021
There was one finalizer being called for each level of inheritance. For example Gst.Message -> Gst.MiniObject -> GLib.Opaque ends with 2 finalizers being called, one calling gst_mini_object_unref and another one calling gst_message_unref The following implementation will only call once the unref function for the highest class in the hierarchy Fixes #54
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This issue has been detected in the GStreamer bindings https://gitlab.freedesktop.org/gstreamer/gstreamer-sharp/-/issues/58
The generator is inserting finalizers without checking if the base class for this object has one already. In objects with the following hierarchy Gst.Message -> Gst.MiniObject -> GLib.Opaque the same finalizer is inserted for both Gst.Message and Gst.MiniObject.
When the GC kicks in, both finalizers are called ending with a double unref.
The text was updated successfully, but these errors were encountered: