GNOME Bugzilla – Bug 775898
scaletempo: crash in Totem when doing Slow -> Fast -> Slow playback
Last modified: 2017-01-23 08:20:26 UTC
Tried out the speed control in the new Totem with some MP3 files. Opened one, set the speed to 0.75x, then clicked another in Nautilus to open it. It started playing, at normal speed; going into the speed menu, it still said 0.75x. I set it back to "normal" speed, no audible change. Then I tried setting it back to 0.75x speed, which then makes totem crash (every time, on Fedora 25).
Thanks for taking the time to report this. Without a stack trace from the crash it's very hard to determine what caused it. Can you get us a stack trace? Please see https://wiki.gnome.org/Community/GettingInTouch/Bugzilla/GettingTraces for more information on how to do so. When pasting a stack trace in this bug report, please reset the status of this bug report from NEEDINFO to its previous status. Thanks in advance!
Hmmm, I'd like to help (I presume it does not happen on your machine), but Totem does not have the ability to open custom files easily anymore (no ctrl+O nor "Open file" menus like it used to have, AFAICS), nor does it let me search for recently used MP3 files... and the way I triggered the problem was by opening the files in Totem through Nautilus, which means I can't just launch "gdb totem" or "gdb nautilus" and reproduce it through gdb with my current knowledge. I'd need some pointers please.
ABRT to the rescue! https://bugzilla.redhat.com/show_bug.cgi?id=1403418
gdb --args totem foobar.mp3 and get the backtrace. Anyway, backtrace from the downstream bug: #0 __memmove_avx_unaligned_erms at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:396 #1 memcpy at /usr/include/bits/string3.h:53 #2 fill_queue at gstscaletempo.c:261 #3 gst_scaletempo_transform at gstscaletempo.c:490 #4 default_generate_output at gstbasetransform.c:2183 #5 gst_base_transform_chain at gstbasetransform.c:2336 #6 gst_pad_chain_data_unchecked at gstpad.c:4205 #7 gst_pad_push_data at gstpad.c:4457 #8 gst_pad_push at gstpad.c:4576 #9 gst_base_transform_chain at gstbasetransform.c:2372
Let's try again. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `/usr/bin/totem --gapplication-service'. Program terminated with signal SIGSEGV, Segmentation fault.
+ Trace 236964
Thread 1 (Thread 0x7f66f2585700 (LWP 17536))
*** Bug 775923 has been marked as a duplicate of this bug. ***
Updating bug description to something more useful.
omap / pout being NULL is probably problematic. Can you get a debug log also, ideally a full one at level 6? Will take a look later, but this was definitely working some weeks before 1.10 with the playback-test application. Which exact version of gst-plugins-good is that?
That's gst plugins good 1.10.2 from Fedora 25... I don't really know how to get debug logs or gdb output out of this because you need to launch 2-3 files "in succession" without stopping the app, so it's not like you can just do that from the commandline AFAIK...
Can't you just do totem foo1.mp3 foo2.mp3 foo3.mp3 ?
(In reply to Tim-Philipp Müller from comment #10) > Can't you just do totem foo1.mp3 foo2.mp3 foo3.mp3 ? As I already mentioned in comment 4. Not sure why it's that weird. (In reply to Jean-François Fortin Tam from comment #9) > That's gst plugins good 1.10.2 from Fedora 25... > > I don't really know how to get debug logs https://wiki.gnome.org/Apps/Videos/BugReporting
I can reproduce it
Backporting to 1.10 later. Please confirm that this also fixes the problem for you. commit fe2ae2c0f7fccb6e9cb483a188a15e9d4ea2909e Author: Sebastian Dröge <sebastian@centricular.com> Date: Sun Dec 11 13:27:27 2016 +0200 scaletempo: Ensure to reinit buffers whenever they were not allocated yet That is, whenever we go through start/stop we have to ensure that on the next opportunity the buffers are reallocated again. Otherwise the buffers might be NULL because the element was reused with the same configuration as before (i.e. set_caps() wouldn't have reinited the buffers). https://bugzilla.gnome.org/show_bug.cgi?id=775898
*** Bug 775499 has been marked as a duplicate of this bug. ***
*** Bug 777602 has been marked as a duplicate of this bug. ***