GNOME Bugzilla – Bug 155008
LoTr movie segfaulting with gstreamer+totem
Last modified: 2004-12-22 21:47:04 UTC
[cschalle@cschalle movies]$ totem lotr_e3_large.mov 00000000 (0xf6d33abb): 53 4d 49 20 53 45 51 48 00 00 00 05 e5 00 3c 1d SMI SEQH......<. 00000010 (0xf6d33acb): c0 00 00 00 00 ..... Segmentation fault Movie to be found here: http://download.nvidia.com/downloads/nZone/videos/lotr_e3_large.mov Tested to work with mplayer
Appears to be a heisenbug, since it doesn't happen when debugged, and happens on FC3 but not Debian/sid.
Hoping Dave can reproduce with any of those... I'm pretty much clueless for this bug, I fail to understand this part of qtdemux right now. Maybe in the future... valgrind --tool=memcheck gst-launch-0.8 filesrc location=~/Media/bugs/lotr_e3_large.mov ! qtdemux .video_00 ! ffdec_mpeg4 ! fakesink crashes valgrind. valgrind --tool=memcheck gst-launch-0.8 filesrc location=~/Media/bugs/lotr_e3_large.mov ! qtdemux works fine. gst-launch-0.8 filesrc location=~/Media/bugs/lotr_e3_large.mov ! qtdemux crashes. Also in gdb. gst-launch-0.8 filesrc location=~/Media/bugs/lotr_e3_large.mov ! qtdemux .video_00 ! ffdec_mpeg4 ! fakesink crashes. Als in gdb. Both of the above also crash with gnomevfssrc, so it's not write-to-readonly-buffer. Backtrace: Program received signal SIGSEGV, Segmentation fault.
+ Trace 51564
Thread NaN (LWP 13402)
By turning on debugging, I get this right before the crash: LOG (0x97708d8 - 305384:41:29.709066000) qtdemux(13419) qtdemux.c(1113):qtdemux_parse: qtdemux_parse buffer 0xf6dc8a61 length 111 LOG (0x97708d8 - 305384:41:29.709476000) qtdemux(13419) qtdemux.c(1124):qtdemux_parse: parsing 'SVQ3', length=111 LOG (0x97708d8 - 305384:41:29.712835000) qtdemux(13419) qtdemux.c(1276):qtdemux_parse: parsing in SVQ3 LOG (0x97708d8 - 305384:41:29.712938000) qtdemux(13419) qtdemux.c(1113):qtdemux_parse: qtdemux_parse buffer 0xf6dc8abb length 1397573920 ERROR (0x97708d8 - 305384:41:29.713032000) qtdemux(13419) qtdemux.c(1357):qtdemux_type_get: unknown QuickTime node type SEQH LOG (0x97708d8 - 305384:41:29.713123000) qtdemux(13419) qtdemux.c(1124):qtdemux_parse: parsing 'SEQH', length=1397573920 Segmentation fault So it crashes inside SVQ3 atom parsing. Here's the SVQ3 atom hexdata: 0002DA50 64 00 00 00 00 00 00 00 01 00 00 00 6F 53 56 51 d...........oSVQ 0002DA60 33 00 00 00 00 00 00 00 01 00 03 03 05 53 4D 49 3............SMI 0002DA70 20 00 00 00 00 00 00 04 00 02 80 01 E0 00 48 00 .............H. 0002DA80 00 00 48 00 00 00 00 00 00 00 01 10 53 6F 72 65 ..H.........Sore 0002DA90 6E 73 6F 6E 20 56 69 64 65 6F 20 33 00 00 00 00 nson Video 3.... 0002DAA0 00 00 00 00 00 00 00 00 00 00 00 00 18 FF FF 00 ................ 0002DAB0 00 00 15 53 4D 49 20 53 45 51 48 00 00 00 05 E5 ...SMI SEQH..... 0002DAC0 00 3C 1D C0 00 00 00 00 00 00 00 18 73 74 74 73 .<..........stts By turning on debugging inside the SVQ3 atom parsing, I get this: version 00030305 tlen = 16 string = Sorenson Video 3 00000000 (0xf6a18ab3): 53 4d 49 20 53 45 51 48 00 00 00 05 e5 00 3c 1d SMI SEQH......<. 00000010 (0xf6a18ac3): c0 00 00 00 00 ..... Something's wrong here, becayse unless I'm completely wrong about quicktime (which is possible), the last four zeroes are part of the next node, not this one. So then it touches bufferspace that it doesn't own. No wonder that valgrind doesn't fetch this, because we're simply touching mmap'ed buffer areas so that memory does actually exist and is completely accessible. Not sure why it crashes then. Still not completely sure how to fix this then, because the code contains some assumptions of which I'm not sure whether they're correct. Anyway, Dave, maybe this helps in fixing this issue.
On closer look... LOG (0x97708d8 - 305384:41:29.712938000) qtdemux(13419) qtdemux.c(1113):qtdemux_parse: qtdemux_parse buffer 0xf6dc8abb length 1397573920 looks kinda suspicious... :).
Created attachment 33330 [details] [review] quickfix The above is a quickfix that fixes the crash for me. It's not right, becuase I believe the atom isn't parsed correctly. Video plays for me now, however. Qtdemux needs more such consistency checks (as do other demuxers).
Dave did something similar that's supposed to be the "more consistency checks", this plays fine now.