After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 620119 - [dvdspu] Program received signal SIGSEGV, Segmentation fault.
[dvdspu] Program received signal SIGSEGV, Segmentation fault.
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: 0.10.23
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-05-30 20:07 UTC by Cristian Aravena Romero
Modified: 2011-08-23 08:16 UTC
See Also:
GNOME target: ---
GNOME version: 2.29/2.30


Attachments
gdb-totem.txt (16.06 KB, text/plain)
2010-05-30 20:07 UTC, Cristian Aravena Romero
  Details
gdb-totem.txt (42.52 KB, text/plain)
2010-05-30 20:28 UTC, Cristian Aravena Romero
  Details
dvdspu: do not clear out high bits from display area (1.66 KB, patch)
2011-08-22 15:58 UTC, Vincent Penquerc'h
committed Details | Review

Description Cristian Aravena Romero 2010-05-30 20:07:29 UTC
Created attachment 162336 [details]
gdb-totem.txt

Open bug in Launchpad.net:
https://bugs.launchpad.net/bugs/587612

Open totem and load film. In minutes/seconds totem frozen

Test 1: http://launchpadlibrarian.net/49402115/Sample.mkv
Test 2: http://launchpadlibrarian.net/49403492/Sample_2.mkv
Comment 1 Cristian Aravena Romero 2010-05-30 20:28:31 UTC
Created attachment 162340 [details]
gdb-totem.txt
Comment 2 Cristian Aravena Romero 2010-05-30 21:44:35 UTC
Bug in LWP27885 ?

[Switching to Thread 0xb5affb70 (LWP 27885)]
0x01159008 in __memset_sse2 () at ../sysdeps/i386/i686/multiarch/memset-sse2.S:267
267	../sysdeps/i386/i686/multiarch/memset-sse2.S: No such file or directory.
	in ../sysdeps/i386/i686/multiarch/memset-sse2.S
Comment 3 Cristian Aravena Romero 2010-05-30 23:21:05 UTC
@t.i.m please url of git =) I want to see the patch =)
Comment 4 Tim-Philipp Müller 2010-05-30 23:27:21 UTC
There is no patch, I have just confirmed that the issue still happens with the git version.
Comment 5 Tim-Philipp Müller 2010-05-31 00:23:05 UTC
valgrind output:

==22441== Invalid write of size 1
==22441==    at 0x4C240A8: memset (mc_replace_strmem.c:586)
==22441==    by 0x1ADE45C9: gstspu_clear_comp_buffers (gstdvdspu-render.c:42)
==22441==    by 0x1ADE6EBF: gstspu_vobsub_clear_comp_buffers (gstspu-vobsub-render.c:362)
==22441==    by 0x1ADE766E: gstspu_vobsub_render (gstspu-vobsub-render.c:505)
==22441==    by 0x1ADE1611: gstspu_render (gstdvdspu.c:637)
==22441==    by 0x1ADE1352: dvdspu_handle_vid_buffer (gstdvdspu.c:602)
==22441==    by 0x1ADE113F: gst_dvd_spu_video_chain (gstdvdspu.c:527)
==22441==    by 0x4E8450C: gst_pad_chain_data_unchecked (gstpad.c:4132)
==22441==    by 0x4E84DFD: gst_pad_push_data (gstpad.c:4361)
==22441==    by 0x89B0C66: gst_base_transform_chain (gstbasetransform.c:2161)
==22441==    by 0x4E8450C: gst_pad_chain_data_unchecked (gstpad.c:4132)
==22441==    by 0x4E84DFD: gst_pad_push_data (gstpad.c:4361)
==22441==  Address 0x1b407750 is 0 bytes after a block of size 2,560 alloc'd
==22441==    at 0x4C221A7: malloc (vg_replace_malloc.c:195)
==22441==    by 0x4C22221: realloc (vg_replace_malloc.c:476)
==22441==    by 0x579B33E: g_realloc (gmem.c:171)
==22441==    by 0x1ADE026B: gst_dvd_spu_video_set_caps (gstdvdspu.c:351)
==22441==    by 0x4E83A06: gst_pad_set_caps (gstpad.c:2613)
==22441==    by 0x4E84621: gst_pad_chain_data_unchecked (gstpad.c:4114)
==22441==    by 0x4E84DFD: gst_pad_push_data (gstpad.c:4361)
==22441==    by 0x89B0C66: gst_base_transform_chain (gstbasetransform.c:2161)
==22441==    by 0x4E8450C: gst_pad_chain_data_unchecked (gstpad.c:4132)
==22441==    by 0x4E84DFD: gst_pad_push_data (gstpad.c:4361)
==22441==    by 0x81568C8: gst_subtitle_overlay_video_sink_chain (gstsubtitleoverlay.c:1725)
==22441==    by 0x4E8450C: gst_pad_chain_data_unchecked (gstpad.c:4132)
==22441==
Comment 6 Vincent Penquerc'h 2011-08-22 15:58:14 UTC
Created attachment 194381 [details] [review]
dvdspu: do not clear out high bits from display area

http://dvd.sourceforge.net/spu_notes does not mention that high bits
are to be masked, and not clearing them makes a sample work, where
clearing them yielded left > right.
History does not shed any light, as tracing this code's origin shows
the same bitmasks being there in 2007 when it was imported.
Comment 7 Vincent Penquerc'h 2011-08-22 15:59:27 UTC
I could repro this with gst-launch and dvdspu.
Now fixed, though I wonder about whether clearing those bits could break other DVDs, as I've no idea where those masks came from, but possibly from experimenting with some DVDs...
Comment 8 Jan Schmidt 2011-08-22 16:12:18 UTC
I don't recall where the masks come from, although I have a vague feeling the values aren't allowed to be > 1023 in the spec (DVD are maximum 1024x768 after scaling) - so these DVDs would be out of spec. I think changing the masks is the right way to go, as long as the rest of the code handles larger values OK.
Comment 9 Vincent Penquerc'h 2011-08-22 16:22:06 UTC
The only "spec" I've seen is reverse engineering documentation, so any subtlety is probably left unseen unless some sample happened to trigger it.

It's possible that the SPU display area was modified when the movie was encoded though. Or also that newer DVDs "break" the spec to allow for larger resolution. The movie here was 1280x720, which may or may not have been the resolution on the DVD...
Comment 10 Jan Schmidt 2011-08-22 16:33:02 UTC
1280x720 isn't a DVD resolution - so this is someone extending the DVD SPU format for higher resolutions - which makes expanding the masks definitely the right move.

The highest specified DVD video resolution is 720x576 (PAL) or 720x480 (NTSC) , that gets expanded out to 1024x576/1024x480 for widescreen presentations before the subpicture is overlaid.
Comment 11 Sebastian Dröge (slomo) 2011-08-23 08:15:57 UTC
commit c437541791bfeac0c7972c6402a50f69b7a2b041
Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk>
Date:   Mon Aug 22 16:52:13 2011 +0100

    dvdspu: do not clear out high bits from display area
    
    http://dvd.sourceforge.net/spu_notes does not mention that high bits
    are to be masked, and not clearing them makes a sample work, where
    clearing them yielded left > right.
    History does not shed any light, as tracing this code's origin shows
    the same bitmasks being there in 2007 when it was imported.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=620119