GNOME Bugzilla – Bug 602847
[dvdspu] Segfaults on seeking in matroska file
Last modified: 2011-01-24 18:47:55 UTC
I have totem segfaulting on a matroska file containing theora and vorbis, plus a bitmap subtitle. Stacktrace: Program received signal SIGSEGV, Segmentation fault. _int_malloc (av=<value optimised out>, bytes=<value optimised out>) at malloc.c:4311 4311 malloc.c: No such file or directory. in malloc.c (gdb) bt full
+ Trace 219266
atk_object_set_name() crashes in malloc which usually indicates memory corruption. Any chance to get a better backtrace by running totem in valgrind?
This is the first time I used Valgrind, let me know if the pasted info below is not what you need. When running in Valgrind, it doesn't segfault, but prints a lot of output to the terminal when i seek. ==23342== Invalid write of size 1 ==23342== at 0x4026B88: memset (mc_replace_strmem.c:586) ==23342== by 0xCBA1079: ??? (in /usr/lib/gstreamer-0.10/libgstdvdspu.so) ==23342== by 0xCBA3328: ??? (in /usr/lib/gstreamer-0.10/libgstdvdspu.so) ==23342== by 0xCB9D083: ??? (in /usr/lib/gstreamer-0.10/libgstdvdspu.so) ==23342== by 0xCB9F6A5: ??? (in /usr/lib/gstreamer-0.10/libgstdvdspu.so) ==23342== by 0xCBA04A8: ??? (in /usr/lib/gstreamer-0.10/libgstdvdspu.so) ==23342== by 0x4123A94: gst_pad_chain_data_unchecked (gstpad.c:4042) ==23342== by 0x41245FF: gst_pad_push_data (gstpad.c:4271) ==23342== by 0x4068867: gst_base_transform_chain (gstbasetransform.c:2081) ==23342== by 0x4123A94: gst_pad_chain_data_unchecked (gstpad.c:4042) ==23342== by 0x41245FF: gst_pad_push_data (gstpad.c:4271) ==23342== by 0x7FDF4CC: gst_queue_loop (gstqueue.c:1048) ==23342== Address 0x9d04f84 is 4 bytes after a block of size 1,424 alloc'd ==23342== at 0x4024C1C: malloc (vg_replace_malloc.c:195) ==23342== by 0x4024CA6: realloc (vg_replace_malloc.c:476) ==23342== by 0x4D261CE: g_realloc (gmem.c:170) ==23342== by 0xCB9D3BB: ??? (in /usr/lib/gstreamer-0.10/libgstdvdspu.so) ==23342== by 0x411CC36: gst_pad_set_caps (gstpad.c:2526) ==23342== by 0x411D613: gst_pad_configure_sink (gstpad.c:2582) ==23342== by 0x4123B79: gst_pad_chain_data_unchecked (gstpad.c:4024) ==23342== by 0x41245FF: gst_pad_push_data (gstpad.c:4271) ==23342== by 0x4068867: gst_base_transform_chain (gstbasetransform.c:2081) ==23342== by 0x4123A94: gst_pad_chain_data_unchecked (gstpad.c:4042) ==23342== by 0x41245FF: gst_pad_push_data (gstpad.c:4271) ==23342== by 0x7FDF4CC: gst_queue_loop (gstqueue.c:1048)
Looks good. Probably a bug in the subtitle handling. Could you please make the file available somewhere for download?
I can confirm that a file generated using the same DVD ripper, but without subtitles does not crash totem on seeking, so it's probably in the subtitling code. I've put the file at http://www.nbi.dk/~hunziker/Gladiator.mkv
Well, I can't trigger a crash on my machine, but it is definitely drawing the subpictures completely wrong. For interest's sake, could you confirm the version of gst-plugins-bad you have installed (that's where the dvdspu component comes from).
That's 0.10.14 in Ubuntu Karmic. Can somebody else get it to crash?
You're right - I neglected to test the installed dvdspu. This patch, after 0.10.14, probably fixes the crash. The rendering is still completely incorrect, however: commit f248986ba4f2f979dc289e2a3593d010f5333397 Author: Jan Schmidt <thaytan@noraisin.net> Date: Tue Sep 22 01:16:47 2009 +0100 dvdspu: Fix rendering and add guards Fix the rendering when we hit the right hand side of the display area, by resetting to the correct X coordinate, and add some more guards against bad PGS data.
Oh, actually - that patch only touches PGS code, so is completely irrelevant. I can't see any other patches that would affect the crash - so the difference is probably just the debug vs stripped build touching memory differently.
I do get an invalid write from the dvdspu element, though no crash. That video was apparently resized, but the SPUs still write to the original position, and thus end up displayed *below* the video. This is probably what causes the problem, if there's no guard against that. Looking into it more...
Created attachment 178055 [details] [review] dvdspu: don't write clipped lines to the output buffer We may not increment the output pointer, but it'll still be just off the end of the allocated area.
Looks correct to me, I'll push this after release.
commit c3d05d6006ed78d0d470ab7bbe9436fd43c60d5e Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk> Date: Tue Jan 11 15:52:03 2011 +0000 dvdspu: don't write clipped lines to the output buffer We may not increment the output pointer, but it'll still be just off the end of the allocated area. https://bugzilla.gnome.org/show_bug.cgi?id=602847