gst_discoverer_new() trouble with pthread
Locked
 
|
I am having a strange problem with gst_discoverer_new(), and
gst_discoverer_discover_uri() which I suspect has something to do with pthread interaction. In short, when I call gst_discoverer_new() from my program on the original thread, there is no problem with that call. When I call it in a thread created after the program is up and running, I get crash. (see GDB back-trace below, on Ubuntu 18.10) (gdb) bt #0 0x00007ffff6741e97 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x00007ffff6743801 in __GI_abort () at abort.c:79 #2 0x00007ffff678c897 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff68b9b9a "%s\n") at ../sysdeps/posix/libc_fatal.c:181 #3 0x00007ffff679390a in malloc_printerr (str=str@entry=0x7ffff68bb3f0 "malloc_consolidate(): invalid chunk size") at malloc.c:5350 #4 0x00007ffff6793bae in malloc_consolidate (av=av@entry=0x7ffff6aeec40 <main_arena>) at malloc.c:4441 #5 0x00007ffff67977d8 in _int_malloc (av=av@entry=0x7ffff6aeec40 <main_arena>, bytes=bytes@entry=2049) at malloc.c:3703 #6 0x00007ffff67988f5 in _int_realloc (av=av@entry=0x7ffff6aeec40 <main_arena>, oldp=oldp@entry=0x5555557d0330, oldsize=oldsize@entry=1040, nb=nb@entry=2064) at malloc.c:4570 #7 0x00007ffff679bf9b in __GI___libc_realloc (oldmem=0x5555557d0340, bytes=2048) at malloc.c:3230 #8 0x00007ffff6b45ae0 in g_realloc () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #9 0x00007ffff6e307ff in g_signal_newv () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #10 0x00007ffff6e30c9d in g_signal_new_valist () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #11 0x00007ffff6e30d8e in g_signal_new () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #12 0x00007ffff0389b8f in () at /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstplayback.so #13 0x00007ffff6e3b419 in g_type_class_ref () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #14 0x00007ffff6e20ef8 in g_object_new_with_properties () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #15 0x00007ffff6e21961 in g_object_new () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #16 0x00007ffff70bd432 in gst_element_factory_create () at /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0 #17 0x00007ffff70bd51e in gst_element_factory_make () at /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0 #18 0x00007ffff73ba2c1 in () at /usr/lib/x86_64-linux-gnu/libgstpbutils-1.0.so.0 #19 0x00007ffff6e3e9c5 in g_type_create_instance () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #20 0x00007ffff6e1f748 in () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #21 0x00007ffff6e215c0 in g_object_new_valist () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #22 0x00007ffff6e21939 in g_object_new () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #23 0x00007ffff73badd7 in gst_discoverer_new () at /usr/lib/x86_64-linux-gnu/libgstpbutils-1.0.so.0 So I tried to move the gst_discoverer_new call near the start of the thread's code, and the crash goes away if it is called prior to a call to pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL); If it move the gst_discoverer_new() call just after the ptherad call, I get a crash again, similar back-trace. As a side note, gst_discoverer_discover_uri() call fails in a thread, same sort of back-trace, even when the gst_discoverer_new call succeeds when called in the main thread and when the discoverer object is protected my a pthread mutex. Note that I am NOT using the glib main-loop at all in my program, and it has a lot of threads running, unrelated to gstreamer. Is there something I am missing with respect to pthread use with the discoverer object? Thanks, Ethan Funk -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
I discoverer a little more information that might be of interest: This may
not be a pthread issue. I stripped down my problem code bit by bit until the gstreamer code no longer failed. The culprit appears to be jack2. If my code does NOT connect to a jack server using jack_client_open() call, then gst_discoverer_new() and all subsequent related discoverer calls work flawlessly. Is there some know incompatibility between jack2 and gstreamer on Ubuntu 18.10? maybe gst_discoverer is trying to interact with the system default audio interface, but jack grabbed it? Assuming this is true, since discoverer isn't actually going to play audio, can a dummy device be set for gstreamer use instead, somehow? Thanks, Ethan... -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
In reply to this post by defunked
And more information regarding this problem: If I switch the Ubuntu 18.10
(pulseaudio) default system sound to a different device than Jack2 uses prior to running my program, with it's jack server connections code in place, then there are no crashes on any gst_discoverer related calls, and gst_discoverer works as expected. Only when when the jack2 server has taken the same device as system sound default does the crash happen. So this is clearly an audio device problem. But why is gst_discoverer in need of an audio device? Is this a gstreamer1.0 bug, or is there something I need to do to get gst_discoverer calls to not attempt to grab the default audio interface? Since gst_discoverer isn't going to play anything, I would not expect it to need any sink in the pipeline it presumable assemble to get media information. Any help would be greatly appreciated. Ethan... -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
Can anyone direct me to the source code area where I might find the
gst_discoverer implementation so I can investigate this? I had a look at the gstreamer project source tree, and it is of course a HUGE project. Also, with a different pulseaudio audio device selected that the device jack is using, I still get a crash when my code I use gst_discoverer in a thread, even though it work fine in the original application thread. Ethan... -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: gst_discoverer_new() trouble with pthread
|
|
Le sam. 6 avr. 2019 06 h 10, defunked <[hidden email]> a écrit : Can anyone direct me to the source code area where I might find the Remember that GstDiscoverer async API is one of the rare GST API that do depends on a GMainContext / GMainLoop. When you run such a loop in a seperate thread, you need special care as I indicated in our API doc, which reminds the need to call g_main_context_push_thread_default()
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |