Bug#721637: libgstreamer-plugins-bad0.10-0: gstreamer hangs in gst_h264_parse_check_valid_frame() for some files

Steffen Kieß s-kiess at web.de
Mon Sep 2 15:58:58 UTC 2013


Package: libgstreamer-plugins-bad0.10-0
Version: 0.10.23-7.1
Severity: important

gstreamer runs into an endless loop when reading some files. This e.g. will
cause /usr/lib/rhythmbox/rhythmbox-metadata to generate 100% CPU load without
doing anything when encoutering such files.

Steps to reproduce:
steffen at fips:/tmp > printf
'\x00\x00\x01\x0a\x00\x00\x00\x01\x0a\x00\x00\x00\x00\x00' > file
steffen at fips:/tmp > hexdump -C file
00000000  00 00 01 0a 00 00 00 01  0a 00 00 00 00 00        |..............|
0000000e
steffen at fips:/tmp > gst-discoverer-0.10 file
Analyzing file:///tmp/file

gst-discover-0.10 will hang and generates 100% load.

Backtrace of the running thread:
Thread 2 (Thread 0x7fd0bfde1700 (LWP 31862)):
#0  0x00007fd0c711fae4 in gst_byte_reader_masked_scan_uint32
(reader=reader at entry=0x7fd0bfde0b40, mask=mask at entry=4294967040,
pattern=pattern at entry=256, offset=offset at entry=0, size=size at entry=6) at
gstbytereader.c:994
#1  0x00007fd0c020d1f2 in scan_for_start_codes (size=6, data=0x178a028 "\n") at
gsth264parser.c:469
#2  gst_h264_parser_identify_nalu_unchecked (nalparser=<optimized out>,
data=data at entry=0x178a020 "", offset=8, size=size at entry=14,
nalu=nalu at entry=0x7fd0bfde0c60) at gsth264parser.c:1190
#3  0x00007fd0c020d416 in gst_h264_parser_identify_nalu (nalparser=<optimized
out>, data=data at entry=0x178a020 "", offset=<optimized out>, size=size at entry=14,
nalu=nalu at entry=0x7fd0bfde0c60) at gsth264parser.c:1246
#4  0x00007fd0c0437e44 in gst_h264_parse_collect_nal (nalu=0x7fd0bfde0c40,
size=14, data=0x178a020 "", h264parse=0x17eb890) at gsth264parse.c:607
#5  gst_h264_parse_check_valid_frame (parse=0x17eb890, frame=<optimized out>,
framesize=0x7fd0bfde0d08, skipsize=0x7fd0bfde0d0c) at gsth264parse.c:812
#6  0x00007fd0c70fc80c in gst_base_parse_scan_frame
(parse=parse at entry=0x17eb890, frame=frame at entry=0x7fd0bfde0db0,
full=full at entry=1, klass=<error reading variable: Unhandled dwarf expression
opcode 0xfa>, klass=<error reading variable: Unhandled dwarf expression opcode
0xfa>) at gstbaseparse.c:2718
#7  0x00007fd0c7102747 in gst_base_parse_loop (pad=<optimized out>) at
gstbaseparse.c:2821
#8  0x00007fd0ca0c88c4 in gst_task_func (task=0x17f7010) at gsttask.c:327
#9  0x00007fd0c9b68742 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x00007fd0c9b67f45 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#11 0x00007fd0c98e5b50 in start_thread (arg=<optimized out>) at
pthread_create.c:304
#12 0x00007fd0c962fa7d in clone () at
.../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#13 0x0000000000000000 in ?? ()

It seems that in gst_h264_parse_check_valid_frame() pres is set to
GST_H264_PARSER_NO_NAL which causes an endless loop.

This seems to be fixed upstream in 1.1.3: http://cgit.freedesktop.org/gstreamer
/gst-plugins-bad/commit/?id=6a1896d805e05a10bbcafbaf95a1d4b231d573b4 (by
returning an error instead of calling g_assert_not_reached() which is a NOP).



-- System Information:
Debian Release: 7.1
  APT prefers stable
  APT policy: (520, 'stable'), (500, 'proposed-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libgstreamer-plugins-bad0.10-0 depends on:
ii  libc6                            2.13-38
ii  libglib2.0-0                     2.33.12+really2.32.4-5
ii  libgstreamer-plugins-base0.10-0  0.10.36-1.1
ii  libgstreamer0.10-0               0.10.36-1.2
ii  multiarch-support                2.13-38

libgstreamer-plugins-bad0.10-0 recommends no packages.

libgstreamer-plugins-bad0.10-0 suggests no packages.

-- no debconf information



More information about the pkg-gstreamer-maintainers mailing list