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