Description of problem: Anyone of the official FOSDEM videos (http://ftp.belnet.be/mirrors/FOSDEM/2007/) will cause Totem to hang upon completion, you are also unable to drag and drop another video onto the Totem window and have it play once a FOSDEM video is playing. To switch to another video the user thus has to close totem and open it again. Now I realise this is likely a problem with the videos but I saw the same thing with the LCA videos and it would be nice if Totem handled them correctly. Version-Release number of selected component (if applicable): totem-2.18.0-1.fc7 gstreamer-0.10.12-1.fc7 gstreamer-plugins-good-0.10.5-5.fc7 gstreamer-plugins-base-0.10.12-2.fc7 How reproducible: 100% Steps to Reproduce: 1. download and attempt to play any of the videos in question Actual results: Hang on finish, in ability to add a new video during playback. Expected results: correct playback Additional info: I've attached a crash that bug-buddy captured when opening the Welcome.ogg video from FOSDEM, I don't know if it's related to the issue since the videos normally open fine and playback without much trouble (though sometimes you have to open them a few times to get playback to start).
Created attachment 150022 [details] backtrace of crash
Same thing happens with the content we published from FUDCon like the OLPC talk. http://torrent.fedoraproject.org/torrents/fudcon-boston-2007-olpc.ogg.torrent There seems to be something wonky with Ogg Theora decoding - could this be a GStreamer or libtheora issue?
(In reply to comment #0) > Description of problem: <snip> > Additional info: > I've attached a crash that bug-buddy captured when opening the Welcome.ogg video > from FOSDEM, I don't know if it's related to the issue since the videos normally > open fine and playback without much trouble (though sometimes you have to open > them a few times to get playback to start). The crash is in the "bookmark" (recent-files) code. I believe it's either a GTK+ bug, or the one I fixed in Totem 2.18.1 (which should be somewhere near your rawhide repo). #2 <signal handler called> No locals. #3 *__GI___libc_free (mem=0x3d45534e4543494c) at malloc.c:3540 ar_ptr = <value optimized out> p = <value optimized out> hook = (void (*)(void *, const void *)) 0 #4 0x0000003abfc12d56 in bookmark_app_info_free (app_info=0xe6bca0) at gbookmarkfile.c:241 No locals. #5 0x0000003abfc2aadd in IA__g_list_foreach (list=<value optimized out>, func=0x3abfc12d40 <bookmark_app_info_free>, user_data=0x0) at glist.c:495 next = (GList *) 0xdaedd0 #6 0x0000003abfc12ea8 in bookmark_item_free (item=0xb115c0) at gbookmarkfile.c:327 No locals. #7 0x0000003abfc2aadd in IA__g_list_foreach (list=<value optimized out>, func=0x3abfc12e20 <bookmark_item_free>, user_data=0x0) at glist.c:495 next = (GList *) 0xb088a0 #8 0x0000003abfc12dcc in g_bookmark_file_clear (bookmark=0xa8ff40) at gbookmarkfile.c:632 No locals. #9 0x0000003abfc13f3d in IA__g_bookmark_file_load_from_data ( bookmark=0xa8ff40, data=0xe83000 "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<xbel version=\"1.0\"\n xmlns:bookmark=\"http://www.freedesktop.org/standards/desktop-bookmarks\"\n xmlns:mime=\"http://www.freedesktop.org/standards/shared-m"..., length=399005, error=0x7fff36bcdf88) at gbookmarkfile.c:1660 parse_error = <value optimized out> __PRETTY_FUNCTION__ = "IA__g_bookmark_file_load_from_data" Could you please get an backtrace of the hang, when Totem fails to load the file again?
Created attachment 151893 [details] New backtrace Totem still hangs when I open one of those Ogg Theora files, it doesn't crash in a manner bug-buddy can catch so I attached to the process and got the attached backtrace.
It's still crashing in the same place: #6 0x0000003cc62304d5 in raise () from /lib64/libc.so.6 #7 0x0000003cc6231e50 in abort () from /lib64/libc.so.6 #8 0x0000003cc6268afb in __libc_message () from /lib64/libc.so.6 #9 0x0000003cc626ffc3 in _int_free () from /lib64/libc.so.6 #10 0x0000003cc627369c in free () from /lib64/libc.so.6 #11 0x0000003cc7612e71 in bookmark_item_free (item=0xc99a80) at gbookmarkfile.c:315 Which version of Totem are you using?
totem-2.18.0-1.fc7
I believe I mentioned it should already be fixed in Totem 2.18.1. Test 2.18.1, and feel free to re-open this bug if the problem persists.
I hate to disappoint but the FOSDEM videos still cause totem to hang even using 2.18.1.
Bastian, is this a glib issue ? Can we get hold of the ~/.recently-used.xbel file that is causing this crash ?
(In reply to comment #9) > Bastian, is this a glib issue ? Can we get hold of the ~/.recently-used.xbel > file that is causing this crash ? You're right, it looks like one. David, could you attach your ~/.recently-used.xbel file to this issue, or send it to me privately?
David provided the xbel file in private.
Probably a problem with the FAM patch at gtk+-2.10.3-fam.patch
We are getting awfully close to release and this one is still around, it would be nice if we at least handled Ogg Theora videos correctly, anything I can try to narrow this down?
I looked at this a bit, but I don't believe the problem is with the fam patch. One way to make that 100% clear would be to rebuild gtk2 without the fam patch and see if the problem goes away.
This still happens with gtk2-2.11.1-1.fc8.src.rpm which has the fam patch commented out by default.
Created attachment 158102 [details] Totem terminal out I decided to test this one again and provide terminal output and a backtrace based on the versions currently in F8 Development. gstreamer-0.10.13-2.fc8 gstreamer-plugins-base-0.10.13-2.fc8 gstreamer-plugins-good-0.10.6-1.fc8 totem-2.19.4-2.fc8 gtk2-2.11.4-1.fc8 glib2-2.13.5-1.fc8 glibc-2.6-3 I can't help but notice that glibc reports that it detected a double free, that sounds bad to me.
Created attachment 158103 [details] New backtrace
I get it to crash as well, reliably. It's crashing in on_playlist_change_name() which doesn't make much sense. Running under valgrind, I get the following errors from the theora decoder (that's using the xine-lib backend): ==4965== Thread 5: ==4965== Invalid write of size 8 ==4965== at 0x1708036F: theora_decode_header (in /usr/lib64/libtheora.so.0.2.0) ==4965== by 0x19F9D237: theora_decode_data (xine_theora_decoder.c:188) ==4965== by 0x3FD721AA91: video_decoder_loop (video_decoder.c:375) ==4965== by 0x350CA061B4: start_thread (pthread_create.c:296) ==4965== by 0x350A6CE28C: clone (in /lib64/libc-2.5.so) ==4965== Address 0x4F152E8 is 0 bytes after a block of size 0 alloc'd ==4965== at 0x4A04BA2: calloc (vg_replace_malloc.c:279) ==4965== by 0x17080281: theora_decode_header (in /usr/lib64/libtheora.so.0.2.0) ==4965== by 0x19F9D237: theora_decode_data (xine_theora_decoder.c:188) ==4965== by 0x3FD721AA91: video_decoder_loop (video_decoder.c:375) ==4965== by 0x350CA061B4: start_thread (pthread_create.c:296) ==4965== by 0x350A6CE28C: clone (in /lib64/libc-2.5.so) ==4965== ==4965== Invalid read of size 8 ==4965== at 0x17080375: theora_decode_header (in /usr/lib64/libtheora.so.0.2.0) ==4965== by 0x19F9D237: theora_decode_data (xine_theora_decoder.c:188) ==4965== by 0x3FD721AA91: video_decoder_loop (video_decoder.c:375) ==4965== by 0x350CA061B4: start_thread (pthread_create.c:296) ==4965== by 0x350A6CE28C: clone (in /lib64/libc-2.5.so) ==4965== Address 0x4F152E8 is 0 bytes after a block of size 0 alloc'd ==4965== at 0x4A04BA2: calloc (vg_replace_malloc.c:279) ==4965== by 0x17080281: theora_decode_header (in /usr/lib64/libtheora.so.0.2.0) ==4965== by 0x19F9D237: theora_decode_data (xine_theora_decoder.c:188) ==4965== by 0x3FD721AA91: video_decoder_loop (video_decoder.c:375) ==4965== by 0x350CA061B4: start_thread (pthread_create.c:296) ==4965== by 0x350A6CE28C: clone (in /lib64/libc-2.5.so) ==4965== ==4965== Invalid read of size 8 ==4965== at 0x1708052A: theora_decode_header (in /usr/lib64/libtheora.so.0.2.0) ==4965== by 0x19F9D237: theora_decode_data (xine_theora_decoder.c:188) ==4965== by 0x3FD721AA91: video_decoder_loop (video_decoder.c:375) ==4965== by 0x350CA061B4: start_thread (pthread_create.c:296) ==4965== by 0x350A6CE28C: clone (in /lib64/libc-2.5.so) ==4965== Address 0x4F152E8 is 0 bytes after a block of size 0 alloc'd ==4965== at 0x4A04BA2: calloc (vg_replace_malloc.c:279) ==4965== by 0x17080281: theora_decode_header (in /usr/lib64/libtheora.so.0.2.0) ==4965== by 0x19F9D237: theora_decode_data (xine_theora_decoder.c:188) ==4965== by 0x3FD721AA91: video_decoder_loop (video_decoder.c:375) ==4965== by 0x350CA061B4: start_thread (pthread_create.c:296) ==4965== by 0x350A6CE28C: clone (in /lib64/libc-2.5.so)
I've been debugging this all morning. It seems like libtheora is corrupting the mem causing all kinda issues, esp with gslice & friends. This send me into investigating several dead trails before coming to this conclusion. I then tried switching to the theoraexp decoder included in gstreamer-plugins-bad (which I maintain in the other repo) Notice that for some reason this decoder is disabled in the Makefile of the latest gstreamer-plugins-bad, so if you want to test this you must build it yourself by uncommenting the line adding theora to the SUBDIRS in ext/Makefile of gstreamer-plugins-bad. I then went looking in libtheora svn and found that they are working towards a 1.0alpha8 release, which includes the new experimental decoder. After some fighting with autoxxx and an upstream configure.ac bug, I have managed to build an rpm based on an upstream 1.0alpha8 svn snapshot. I've verified the public header files and this release is 100% ABI compatible with 1.0alpha7! And it fixes this bug :) I've made an srpm of my work available here: SRPM: http://people.atrpms.net/~hdegoede/libtheora-1.0alpha8-0.1.svn13393.fc8.src.rpm SPEC: http://people.atrpms.net/~hdegoede/libtheora.spec I'll attach a specfile diff and the new patch needed.
Created attachment 160188 [details] Specfile diff
Created attachment 160189 [details] New patch needed for the svn snapshot If you add me to the ACL I can import and build this for you if you want.
Erm, about me being able todo the import and building, I'll be leaving for a 6 day vacation tomorrow, so in retrospect its probably better if you do this yourself.
It needs to BR doxygen or it fails to build. I can also comfirm that Theora videos now appear to behave as they should.
Hans, thanks for the SVN snapshot. I can confirm that it fixes the issues for me, too (using Fedora 7/x86_64, updated as of earlier today).
Ogg Theora is the only video format Fedora plays out of the box, it's rather embarrasing that we can't actually use it. Can I bribe someone to put Hans' updated rpm into Rawhide for extended testing so we can get this bug killed? I've been testing it for nearly 2 weeks now, decoding and encoding Ogg Theora files on a daily basis and I have detected no regression.
Yes, also note that this is an F-8 blocker, so the sooner we can get an updated fixed version ready for testing, the better, because if we fix this last minute there will be little time left for testing. As said I would be more then happy to do the committing and building of this, just add me to the ACL.
Hans, can you build packages for F-7 and F-8 please?
(In reply to comment #28) > Hans, can you build packages for F-7 and F-8 please? Done, I've also requested the F-7 build to be pushed to updates -testing.
Thanks Hans, much appreciated.
libtheora-1.0alpha8-0.1.svn13393.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report.
*** Bug 251856 has been marked as a duplicate of this bug. ***
This is fixed, right ?
It is in rawhide, I left this open as it was against F-7, and the F-7 update got delayed because of selinux issues. The currently is a new update in F-7 testing which fixes the selinux stuff, if I don't get any negative feedback for a couple of more days I'll push that also fixing this in F-7.
libtheora-1.0alpha8-0.3.svn13393.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report.
libtheora-1.0alpha8-0.3.svn13393.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.