GNOME Bugzilla – Bug 675943
subtitle editor hangs when opening a video
Last modified: 2013-07-31 07:47:21 UTC
Created attachment 213921 [details] backtrace Using subtitleeditor (current trunk: http://home.gna.org/subtitleeditor/) - when opening most videos, it just hangs. It does not hang always, and the videos sometimes can be opened. It is suggested here http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657327 that the bug was introduced between 0.10.35-1 0.10.35-2 and it also says "The backtrace shows the problem in libgstreamermm-0.10.so.2 but nevertheless the bug is in libgstreamer0.10-0. I had another backtrace with libgstreamer0.10-0 in focus, but then downgraded/upgraded some packages. Downgrading exactly libgstreamer0.10-0 helps." Which I do not make much sense of but maybe someone else does. I am attaching a backtrace, I hope it is useful (generated according to https://wiki.ubuntu.com/Backtrace ). Some other backtraces maybe due to the same issue are here: https://bugs.launchpad.net/ubuntu/+source/subtitleeditor/+bug/991132
It is reported on Launchpad that this only affects 64bit.
Sadly, this backtrace is useless as it lacks debug symbols for most parts. The backtrace on launchpad.net is for a crash in malloc, which usually indicate prior memory corruption. It's possible that a single corruption bug might cause both the malloc crash and the hang though. You can try installing debug symbols (same package names, but with a -debug or -dbg suffix, usually) for all the relevant software (all the gstreamer ones, glib, glibc, libgstreamermm), and run with valgrind (it'll be slow): G_SLICE=always-malloc valgrind /usr/local/bin/subtitleeditor >& /tmp/sevalgrind.log Then reproduce the bug, and hope valgrind caught something interesting. You can also post another trace with the debug info installed, it might shed more light too.
With valgrind, the bug is unreproducible. It is slow, but subtitleeditor repeatedly opens a video that normally crashes it. I tried to install the dbg symbols, so I am attaching the backtrace, if it makes more sense then previously.
Created attachment 215978 [details] hopefully better backtrace
This new backtrace shows: __libc_message (do_abort=2, fmt=0x7ffff3cbf0d0 "*** glibc detected *** %s: %s: 0x%s ***\n" [...] malloc_printerr (action=3, str=0x7ffff3cbc100 "malloc(): memory corruption", ptr=<optimized out>) Something has stomped on the libc arena control structures, and this stack trace is just where the libc realizes, so it does not tell us much about where the actual corruption happened. Shame that valgrind does not see anything though. Maybe it might help if you pass "--trace0-children=yes" (without the quotes) to the valgrind command line, if the corruption happens in a spawned process.
No,--trace-children=yes (with the zero, it did not work) also prevents it from crashing. Can I do anything else?
Nothing useful that I can think of now. I've just installed subtitleeditor on x86_64, and I can load videos and play them with git gstreamer (0.10), so maybe it's a bug in gst that got fixed, but that's guessing.
Maybe it is a .deb specific thing, supposing you are using something else, as it has been reported only for Debian and Ubuntu. But this is a wild guess too. BTW: are you using complex enough videos? Long (an hour, close to 1GB) mp4 videos do the crashing the best for me, .ogg is more often loaded just fine. The best way to try it repeatadly is to launch from terminal "subtitleeditor -v /path/to/video/", if it loads, kill it with ctrl+C and run it again. I tried it ten times with two videos just now and it crashed in about 50 % of cases.
Ah, indeed, I'd tried with ogg ad matroska videos, but this doesn't seem to be why I did not get corruption. I got the glibc error now. I did get interesting output from valgrind though. The numbers below, when related to your earlier point about it seeming to be 64 bit specific, seem suspiciously like something is mixing 32 and 64 bit. There's a read of size 8 4 bytes before the end of a block. It could be another bug though. This all happens before gstreamer gets used, so seems either like a bug in glib's option parsing code (unlikely), or, since these are prebuilt binaries, someone mixing ABIs (more likely). There's an invalid write later in /usr/lib/libgstreamermm-0.10.so.2.0.1, which would quite likely panic the libc malloc checks. This is fairly likely to be the same bug (writing 8 bytes where maybe allocated memory was smaller, assuming 4 byte values). Can't tell for certain offhand though. So I'd say "not gst". Probably whoever compiled one of the libs or subtitleeditor itself mixed up ABIs/archs. Probably subtitleeditor itself, or there'd be several more programs showing the same symptoms (are there ? :)) Anyway, that's all guesswork based on the valgrind reports and the offsets/sizes here. It seems likely, but I can't be 100% sure. That's something that distro people will know better how to check. Please feel free to link to this comment to your distro's bugtracker. I'm tempted to close as NOTGNOME, but I'll wait to see what those people say before doing so. Thanks ==7346== Invalid read of size 8 ==7346== at 0x873101F: wcslen (wcslen.S:48) ==7346== by 0x873976D: wcscoll_l (strcoll_l.c:116) ==7346== by 0x79DE6B9: g_utf8_collate (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3200.1) ==7346== by 0x72ED7FC: Glib::OptionGroup::add_entry_with_wrapper(Glib::OptionEntry const&, GOptionArg, void*) (in /usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1 ==7346== by 0x420446: ??? (in /usr/bin/subtitleeditor) ==7346== by 0x414FFA: ??? (in /usr/bin/subtitleeditor) ==7346== by 0x86B076C: (below main) (libc-start.c:226) ==7346== Address 0xf405a80 is 32 bytes inside a block of size 36 alloc'd ==7346== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==7346== by 0x79BAA38: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3200.1) ==7346== by 0x79DF341: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3200.1) ==7346== by 0x79DE6AB: g_utf8_collate (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3200.1) ==7346== by 0x72ED7FC: Glib::OptionGroup::add_entry_with_wrapper(Glib::OptionEntry const&, GOptionArg, void*) (in /usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1 ==7346== by 0x420446: ??? (in /usr/bin/subtitleeditor) ==7346== by 0x414FFA: ??? (in /usr/bin/subtitleeditor) ==7346== by 0x86B076C: (below main) (libc-start.c:226) ==7346==
Crashes in g_realloc in Gst::PlayBin2::PlayBin2. Can't see any indication of a GStreamer bug so far, something seems to be trampling over memory, or doing a double free or somesuch, perhaps the bindings or the application (or GStreamer). Please provide a valgrind trace that suggests something dodgy is going on in GStreamer.
I tried to mail the upstream maintainer of subtitleeditor but he did not respond, I lack the technical ability to do anything about the bug - if it is not a bug in gstreamer, I guess you can close it.
Alright, sorry about that. I'm sure there's a bug somewhere, just not sure if it's in GStreamer (given the info we have). Please re-open or file a new bug if new information is found.
I exchanged some email with the developer of the upstream software and he came up with this main.cc: #include <iostream> //#include <glibmm.h> #include <gstreamermm.h> int main(int argc, char *argv[]) { Gst::init(argc, argv); std::cout << "Try to create a Gst::PlayBin2 element." << std::endl; Glib::RefPtr<Gst::PlayBin2> playbin = Gst::PlayBin2::create(); if(!playbin) { std::cerr << "Failed to create the playbin2 element." << std::endl; return EXIT_FAILURE; } else std::cout << "Playbin2 element created with success." << std::endl; return EXIT_SUCCESS; } compiled with: g++ main.cc -o test `pkg-config --libs --cflags gstreamermm-0.10` If run, it results in: Try to create a Gst::PlayBin2 element. *** glibc detected *** ./test: malloc(): memory corruption (fast): 0x0000000000abf1e0 *** The upstream developer thinks this is somethingwrong with gstreamer, I have no idea, what do you think?
He actually comments is as this: "If you create a playbin2 element using gstreamer, it is ok. If you create with ElementFactory, it's ok. If you create with PlayBin2, this bug. So, for me it's a Gst::PlayBin2 bug, and it's gstreamermm bug."
Yes, indeed. It seems highly unlikely that just creating a playbin2 element is/was broken in GStreamer. More likely an issue with the gstreamermm bindings (which hardly anyone uses).
Yes, I can reproduce the bug on this amd64 ubuntu 12.04 system also. Apparently it's related to an unreliable method that I had come up with to wrap the plug-in signals. For more of a reference see the following thread: https://mail.gnome.org/archives/gtkmm-list/2012-December/msg00024.html The problem was corrected in gstreamermm-0.10.9.1 and upwards (I just checked to make sure). Maybe ubuntu and debian could use a later version than 0.10.9? As I said in the above mentioned thread, that would fix the problem. I'm sorry from my part.
For the curious, this is the commit that fixed this inadvertently quite some time ago: http://git.gnome.org/browse/gstreamermm/commit/?id=9678d4173cc17677bcc70891861d0f4cd46e48f9
And here's the related one (the one that is referred to in the commit that fixes this): http://git.gnome.org/browse/gstreamermm/commit/?id=d1a6deab637e2d7331cf9eeefee28876688932a2
When opening videos, the same result, what happend? Ubuntu 12.04 LTS x86-x64 libgstreamermm-0.10-2 version 0.10.9-1 subtitleeditor 0.40.0-1~webupd8 Terminal: lester@Mac:~$ subtitleeditor *** glibc detected *** subtitleeditor: malloc(): memory corruption (fast): 0x0000000001b6e300 *** Video Property: Vídeo Resolución 624 x 352 Relación de aspecto 1.7727 Formato DX50 Tasa de bits 1098 kbps Imágenes por segundo 23.976 Códec seleccionado ffodivx Pista de audio inicial Formato 85 Tasa de bits 128 kbps Tasa 48000 Hz Canales 2 Códec seleccionado ffmp3float Pistas de audio nº Idioma Nombre ID 0 <vacío> <vacío> 1 Subtítulos nº Tipo Idioma Nombre ID 0 FILE_SUB <vacío> <vacío> 0
Now everything is fine, the problem is subtitleeditor-0.40.0-1~webupd8, I had to compile (https://gna.org/support/?2920) the source (http://download.gna.org/subtitleeditor/0.40/subtitleeditor-0.40.0.tar.gz), applying the patch (gna.org/support/download.php?file_id=16929), like: Change the line: m_pipeline = Gst::PlayBin2::create("pipeline"); by lines: Glib::RefPtr<Gst::Element> playbin_element = Gst::ElementFactory::create_element("playbin2", "pipeline"); m_pipeline = Glib::RefPtr<Gst::PlayBin2>::cast_dynamic(playbin_element); in the source archive: src/vp/gstplayer.cc and now all is well. Thanks...
The subtitle editor code should work without the patch using gstreamermm-0.10.9.1. The version of gstreamermm being used in ubuntu 12.04 is 0.10.9. The way to know the actual gstreamermm version is using 'pkg-config --modversion gstreamermm-0.10'.
Thanks... lester@Mac:~$ pkg-config --modversion gstreamermm-0.10 0.10.9 Thanks, you're right, of course, but when upgrading gstreamermm with the same patch, should work correctly subtitleeditor and also over time is very small and not spent on auxiliary memory.
Closing because I think a) this seems to be a bug in an older subtitleeditor version and b) gstreamermm now has a fix to make it work with older subtitleeditor versions too. Thanks.