rhythmbox-metadata crashed with SIGSEGV in ape_read_header()

Bug #607718 reported by Daniel J Blueman
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gstreamer0.10-ffmpeg (Ubuntu)
Expired
Low
Unassigned

Bug Description

When rhythmbox is checking my music files, one of the processes that belongs to rhythmbox crashes, and we see in the kernel logs:

ffdemux_ape0:si[2479]: segfault at 4 ip 00007ff48280dfc8 sp 00007ff47f6af880 error 4 in libavformat.so.52.64.2[7ff4827f0000+be000]

ProblemType: Crash
DistroRelease: Ubuntu 10.10
Package: libgstreamer0.10-0 0.10.30-1
Uname: Linux 2.6.35-020635rc5-generic x86_64
Architecture: amd64
CrashCounter: 1
Date: Tue Jul 20 12:51:47 2010
ExecutablePath: /usr/lib/rhythmbox/rhythmbox-metadata
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Alpha amd64 (20100623)
ProcCmdline: /usr/lib/rhythmbox/rhythmbox-metadata unix:tmpdir=/tmp
ProcEnviron:
 PATH=(custom, user)
 LANG=C
 SHELL=/bin/bash
SegvAnalysis:
 Segfault happened at: 0x7ff48280dfc8 <ape_read_header+760>: mov 0x4(%r8,%rax,1),%ecx
 PC (0x7ff48280dfc8) ok
 source "0x4(%r8,%rax,1)" (0x00000004) not located in a known VMA region (needed readable region)!
 destination "%ecx" ok
 Stack memory exhausted (SP below stack segment)
SegvReason: reading NULL VMA
Signal: 11
SourcePackage: gstreamer0.10
StacktraceTop:
 ape_read_header (s=0x7ff47800d5b0,
 av_open_input_stream (ic_ptr=0x1e1a2b0,
 av_open_input_file (ic_ptr=0x1e1a2b0,
 gst_ffmpegdemux_open (demux=0x1e1a1c0)
 gst_ffmpegdemux_loop (demux=0x1e1a1c0) at gstffmpegdemux.c:1339
Title: rhythmbox-metadata crashed with SIGSEGV in ape_read_header()
UserGroups: adm admin audio cdrom dialout dip floppy kvm lpadmin plugdev video
XsessionErrors:
 (polkit-gnome-authentication-agent-1:2075): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
 (npviewer.bin:23680): Gdk-WARNING **: XID collision, trouble ahead

Revision history for this message
Daniel J Blueman (danielblueman) wrote :
visibility: private → public
Revision history for this message
Apport retracing service (apport) wrote :

StacktraceTop:
 ape_read_header (s=0x7ff47800d5b0,
 av_open_input_stream (ic_ptr=0x1e1a2b0,
 av_open_input_file (ic_ptr=0x1e1a2b0,
 gst_ffmpegdemux_loop (demux=0x1e1a1c0)
 gst_task_func (task=0x1e13270) at gsttask.c:271

Revision history for this message
Apport retracing service (apport) wrote : Stacktrace.txt
Revision history for this message
Apport retracing service (apport) wrote : ThreadStacktrace.txt
Changed in gstreamer0.10 (Ubuntu):
importance: Undecided → Medium
tags: removed: need-amd64-retrace
affects: gstreamer0.10 (Ubuntu) → ffmpeg (Ubuntu)
Revision history for this message
Reinhard Tartler (siretart) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. You have reported a crash that actually happened in the libavcodec or libavformat library. In order to be able to actually fix this bug, we must be able to:

1. Reproduce it;
2. Check if it happens with the latest version; and
3. Understand where it actually crashes.

You can help with the first point by attaching an example file to this bug report. In this particular case, it seems that the cause is some APE file. can you reproduce it by using the utility /usr/bin/ffplay from the ffmpeg package? If yes, we'd definitly need a sample. If not, then we have shown that libavformat is able to demultiplex the sample properly and the defect is actually in gstreamer-ffmpeg.

Please note that a proper attachment is preferred over a link to some remote site. Remote sites that are password protected or otherwise restricted (services like rapidshare.com) are absolutely not acceptable. If your file is too large, try to reproduce with the first few MB only. See http://ffmpeg.org/bugreports.html section "Submitting Sample Media" for guidelines.

Changed in ffmpeg (Ubuntu):
importance: Medium → Low
status: New → Incomplete
Revision history for this message
Daniel J Blueman (danielblueman) wrote :

This issue is consistently reproducible and has been an issue for a while. I have unsuccessfully tried to find a way to get filename information when this issue occurs. Under gdb, listing open file descriptors doesn't help, as the data is passed through in a stream. I can of course capture the data, but it'll not be so easy to reproduce with.

Can you provide any help here?

We see a number of function arguments to gst_ffmpegdemux_loop() being rogue (ie size and pos):

#4 gst_ffmpegdemux_loop (demux=0x1e1a1c0) at gstffmpegdemux.c:1339
        ret = <value optimized out>
        res = <value optimized out>
        pkt = {pts = 31535888, dts = 31522496, data = 0x7ff48a087da4 "",
          size = -2013377078, stream_index = 32756, flags = 48,
          duration = 48, destruct = 0x7ff47f6afb80, priv = 0x7ff47f6afac0,
          pos = 31535728, convergence_duration = 140687962021600}
        srcpad = 0x7ff47f6afb6f
        stream = <value optimized out>
        avstream = 0x7ff478001ee0
        outbuf = 0x0
        timestamp = <value optimized out>
        duration = <value optimized out>
        outsize = <value optimized out>
        rawvideo = -2005530688
        __FUNCTION__ = "gst_ffmpegdemux_loop"

Revision history for this message
Reinhard Tartler (siretart) wrote :

yeah, looks like gstreamer0.10-ffmpeg is passing fishy data to libavformat. reassinging.

affects: ffmpeg (Ubuntu) → gstreamer0.10-ffmpeg (Ubuntu)
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for gstreamer0.10-ffmpeg (Ubuntu) because there has been no activity for 60 days.]

Changed in gstreamer0.10-ffmpeg (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.