Open Carbenium opened 7 years ago
From #2 Carbenium
Exactly. It's unmaintained, doesn't ship with any large distro and it couldn't play a track. So pretty useless in my opinion :smile:
arfbtwn
Agreed, did you get that behaviour even with their master branch? I remember experimentally trying it out - had to make some changes to Banshee to get it to compile, see bb1ac56, think I tried it out and it was working at the time.
I just tried it and reproduced a crash, got the below just after/as the player died so we might be able to fix the problem in the bindings.
*** Error in `/usr/bin/mono': double free or corruption (out): 0x00007f030c0181d0 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x6f273)[0x7f0360707273]
/lib64/libc.so.6(+0x748e6)[0x7f036070c8e6]
/lib64/libc.so.6(+0x750ee)[0x7f036070d0ee]
/usr/lib64/libgobject-2.0.so.0(g_value_unset+0x30)[0x7f0357de37a0]
/usr/lib/libgstreamer-1.0.so(gst_structure_free+0xac)[0x7f033f84ce4c]
/usr/lib/libgstreamer-1.0.so(+0xa0f3d)[0x7f033f854f3d]
/usr/lib64/libgobject-2.0.so.0(g_value_unset+0x30)[0x7f0357de37a0]
/usr/lib/libgstreamer-1.0.so(gst_structure_free+0xac)[0x7f033f84ce4c]
/usr/lib/libgstreamer-1.0.so(+0x68c1f)[0x7f033f81cc1f]
[0x40aafff2]
followed by, I think this bit's important:
at <unknown> <0xffffffff>
at (wrapper managed-to-native) Gst.MiniObject.gst_mini_object_unref (intptr) <IL 0x00009, 0x00071>
at Gst.MiniObject/FinalizerInfo.Handler () [0x00007] in /tmp/portage/dev-dotnet/gstreamer-sharp-9999/work/gstreamer-sharp-9999/sources/generated/Gst/MiniObject.cs:233
at GLib.Timeout/TimeoutProxy.Handler () [0x0000f] in /tmp/portage/dev-dotnet/gtk-sharp-9999/work/gtk-sharp-9999/glib/Timeout.cs:50
at (wrapper native-to-managed) GLib.Timeout/TimeoutProxy.Handler () <IL 0x0002b, 0x000d1>
at <unknown> <0xffffffff>
at (wrapper managed-to-native) Gtk.Application.gtk_main () <IL 0x00008, 0x0006a>
at Gtk.Application.Run () [0x00001] in /tmp/portage/dev-dotnet/gtk-sharp-9999/work/gtk-sharp-9999/gtk/Application.cs:133
at Banshee.Gui.GtkBaseClient.Run () [0x0001e] in /home/nicholas/Source/Csharp/banshee/src/Core/Banshee.ThickClient/Banshee.Gui/GtkBaseClient.cs:222
at Banshee.Gui.GtkBaseClient.Startup () [0x00010] in /home/nicholas/Source/Csharp/banshee/src/Core/Banshee.ThickClient/Banshee.Gui/GtkBaseClient.cs:79
at Hyena.Gui.CleanRoomStartup.Startup (Hyena.Gui.CleanRoomStartup/StartupInvocationHandler) [0x00050] in /home/nicholas/Source/Csharp/banshee/src/Hyena/Hyena.Gui/Hyena.Gui/CleanRoomStartup.cs:54
at Banshee.Gui.GtkBaseClient.Startup<T_REF> () [0x00049] in /home/nicholas/Source/Csharp/banshee/src/Core/Banshee.ThickClient/Banshee.Gui/GtkBaseClient.cs:74
at Banshee.Gui.GtkBaseClient.Startup<T_REF> (string[]) [0x00021] in /home/nicholas/Source/Csharp/banshee/src/Core/Banshee.ThickClient/Banshee.Gui/GtkBaseClient.cs:64
at Nereid.Client.Main (string[]) [0x00002] in /home/nicholas/Source/Csharp/banshee/src/Clients/Nereid/Nereid/Client.cs:54
at (wrapper runtime-invoke) <Module>.runtime_invoke_void_object (object,intptr,intptr,intptr) <IL 0x00051, 0x000ef>
Yap. Thats exactly the stack trace I get, too.
gstreamer-sharp
is compiled from source (4af160).
I'm on the feature/lite
branch since Banshee doesn't even start for me on master
. Main window appears but without album browser and than it just hangs. Not, that it would be important for this issue.
Alright. I pinned it down to https://github.com/arfbtwn/banshee/blob/feature/lite/src/Backends/Banshee.GStreamerSharp/Banshee.GStreamerSharp/PlayerEngine.cs#L691
Remove that Dispose
and everything works fine. I think those values are somehow destructed when the tag list is destroyed somewhere in the native code. By calling first Dispose
this leads to the double-free.
A slightly more detailed part of the crash report:
Thread 1 (Thread 0x7f59250fd740 (LWP 20557)):
#0 0x00007f59245f2f7b in __waitpid (pid=20576, stat_loc=0x7ffd27f233bc, options=0) at ../sysdeps/unix/sysv/linux/waitpid.c:29
#1 0x00000000004ac659 in ()
#2 0x00007f59245f3390 in <signal handler called> () at /lib/x86_64-linux-gnu/libpthread.so.0
#3 0x00007f5924038428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#4 0x00007f592403a02a in __GI_abort () at abort.c:89
#5 0x00007f592407a7ea in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x7f59241932e0 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175
#6 0x00007f5924082e0a in _int_free (ar_ptr=<optimised out>, ptr=<optimised out>, str=0x7f59241933f0 "double free or corruption (out)", action=3) at malloc.c:5004
#7 0x00007f5924082e0a in _int_free (av=<optimised out>, p=<optimised out>, have_lock=0) at malloc.c:3865
#8 0x00007f592408698c in __GI___libc_free (mem=<optimised out>) at malloc.c:2966
#9 0x00007f5918dc4450 in g_value_unset (value=value@entry=0x7f58c800d818) at /build/glib2.0-prJhLS/glib2.0-2.48.2/./gobject/gvalue.c:275
#10 0x00007f591050f28c in gst_structure_free (structure=0x1b96cc0) at gststructure.c:383
#11 0x00007f59105174fd in __gst_tag_list_free (list=0x2330f20) at gsttaglist.c:715
#12 0x0000000040948ce0 in ()
#13 0x0000000000000000 in ()
Nice! I was wondering why the track started playing for a short period before the crash, I bet if we follow that call tree back up we'll see the library or Banshee dispose of the list. Are there any other instances in that file where we dispose of a GLib.Value
from a TagList
- I think we're at the point where we can confidently patch this if you want to pull request it?
No other references and there you go : #8 :)
it's a shame GH doesn't use git-cherry to find out if pull requests are merged, it's nice to have the merged symbol on pages like this.
So I assume this means we keep the backend for now?
Oops, there's still the maintenance issue, reopened :)
@nicman23: there's an outstanding issue about maintenance but the thing with open source libraries is that they can seem that way through lack of activity and still work great.
As an example - in our native engine the last commit that did anything with its source was in August 2014 (adbcdb3dc323cbd155443475b445993a39042b83) and that looks like it was a bug fix rather than for any gstreamer changes.
Apart from that the managed engine was one of the newer features in Banshee development before people stopped working on the program, so that's the main reason why I'd like to keep it if possible.
As the NEWS file states
Production-ready GStreamerSharp playback-engine backend, now default
Our managed backend (that already allowed us to have playback working
in the Windows platform) has been migrated to work with the revamped
GStreamerSharp bindings (GObject-Introspection based, and capable of
binding GStreamer 1.0 or newer) and is now the default one for all
platforms.
This paves the way to finish the long-standing goal of completely
removing lower-level languages like C from our codebase, to lower
the barrier of entry to new contributors, reduce complexity and
increase stability.
You can still use the optional unmanaged GStreamer backend, but
before doing so we encourage you to provide us any feedback that
you may have about the managed one (reporting bugs or writing to
our forums or mailing lists), because we will deprecate this one very soon.
So I guess we should try really hard to keep the backend, rescinding my previous uneducated opinion.
A little bit offtopic but: Since this library doesn't ship with any large distro shouldn't it be somehow included in the project? Trying to compile gstreamer-sharp 0.99 in Kubuntu 17.10 throws a lot of "type or namespace xxx could not be found" which I can't possibly fix and the gstreamer-sharp project doesn't have an issues section or similar.
it is for windows mostly, also native is working fine for linux
Sorry again for going offtopic but could you point me to any doc on how to disable the dependency/backend so I can compile banshee on Kubuntu?
this works for arch linux, https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=banshee-git
The gstreamer-sharp binding library is more or less unmaintained (last commit in Arpil 2016). Additionally it isn't shipped with any large distro.
Since we have our own binding + native library I'd suggest to remove the
Banshee.GStreamerSharp
backend.