/usr/bin/mediascanner-service-2.0:*** Error in `mediascanner-service-2.0': double free or corruption (fasttop): ADDR ***

[errors.ubuntu.com bug bridge]

The Ubuntu Error Tracker has been receiving reports about a problem regarding mediascanner2. This problem was most recently seen with version 0.104+14.10.20140825-0ubuntu1, the problem page at https://errors.ubuntu.com/problem/354f10fdaba609ee33dd0a2868637ec79c590b56 and https://errors.ubuntu.com/problem/01fcf2789e27c0abf6922c68c02a408b907fab83 contains more details.

[Chris Gagnon (chris.gagnon)]

There is also this crash that I didn't get a good stacktrace from, it might be the same issue. https://errors.ubuntu.com/problem/a346e9c98732c4d4427686e8d3fa1ae4f5641f72

[Jussi Pakkanen (jpakkane)]

The first stack trace is unfortunately useless. The second one seems to be a bug in GStreamer. That's probably Jim Hodapp's domain.

Mediascanner has protection against files that cause GStreamer to crash the process from under it. It remembers broken files and skips them when it is restarted. Thus Mediascanner should never get stuck in a crash loop. The unfortunate state of media files and gstreamer is that we can probably never get rid of these crashes totally. Therefore unless someone can demonstrate a crash loop in Mediascanner (rather than just one crash per broken file) this bug should probably be downgraded from critical.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Pat McGowan (pat-mcgowan)]

Re-openning on mediascanner since its the use case triggering the many crashes the error tracker shows, 73 in the past two months
We need someone to do analysis

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Chris Gagnon (chris.gagnon)]

error.u.c has a new problem bucket for this crash https://errors.ubuntu.com/problem/01fcf2789e27c0abf6922c68c02a408b907fab83

[Pat McGowan (pat-mcgowan)]

Thomas can we get a read on who can debug this as its seems ownerless

[James Henstridge (jamesh)]

Pat: the underlying problem is that there are bugs in some of the media codecs when faced with invalid files. The bug was deprioritised in mediascanner2 (but not GStreamer!) is because we added code to mitigate the problem by making the media scanner service not rescan a file that caused it to crash previously.

We do have a plan to improve this further in a way that will stop the errors showing up for media scanner. Basically:

1. separate the metadata extraction into a separate process.
2. add this process to the apport blacklist
3. have the media scanner service use the out of process metadata extractor

We haven't been working on this in the short term (i.e. RTM time frame) because it is a fairly disruptive change and we already have a mitigation strategy in place. Further more, any file that crashes media scanner will almost definitely crash the media player too (hence the GStreamer bug task).

Note also that there is unlikely to be a single fix that will stop all future crashes: we will likely continue to find files that cause the codecs to crash as time goes on (and since we have hardware decoders, we will likely find files that only crash on particular devices). If we want to be methodical about this, one strategy would be to:

1. put together a collection of problem media files.
2. write a test harness that will attempt to decode each file and record any crashes (ideally with stack traces if applicable).
3. run this test suite on the devices we care about (desktop, mako, krillin, etc) at regular intervals
4. when new codec crashers are discovered, add those media files to the collection so we can ensure that we don't regress (and have more test cases for when we bring up a new device).

[Jussi Pakkanen (jpakkane)]

This issue can be triggered without any Mediascanner involmement at all. Just issue the following command:

gst-discoverer--1.0 /path/to/files/*

Note that you _must_ pass all files to the command line at once. Looping over the list and invoking gst-discoverer-1.0 on each one separately does not trigger the crash.

gst-discoverer-1.0 is in package gstreamer1.0-plugins-base-apps.

[Olli Ries (ories)]

this bug needs to be targeted after RTM, via ota

[Pat McGowan (pat-mcgowan)]

Will test the fix for bug #1386571 to see if it resolves this issue as well

[Justin McPherson (justinmcp)]

I have tested with the results of #1386571 , and the problem still remains.

[Justin McPherson (justinmcp)]

Code here; https://github.com/jhodapp/gst-plugins-bad/pull/10

[Launchpad Janitor (janitor)]

This bug was fixed in the package gst-plugins-bad1.0 - 1.4.4-2ubuntu2

---------------
gst-plugins-bad1.0 (1.4.4-2ubuntu2) vivid; urgency=medium

  * Refreshing adding-mirsink-and-android-media-over-hybris-support.patch:
    - androidmedia: Fix stagnation when obtaining thumb (LP: #1397997)
    - Don't flush while the dec loop is working (LP: #1364466)
 -- Ricardo Salveti de Araujo <email address hidden> Mon, 08 Dec 2014 23:46:12 -0200

[Pat McGowan (pat-mcgowan)]

confirmed here means approved for milestone

[Launchpad Janitor (janitor)]

This bug was fixed in the package gst-plugins-bad1.0 - 1.2.4-1ubuntu3rtm5

---------------
gst-plugins-bad1.0 (1.2.4-1ubuntu3rtm5) 14.09; urgency=medium

  * Refreshing adding-mirsink-and-android-media-over-hybris-support.patch:
    - androidmedia: Fix stagnation when obtaining thumb (LP: #1397997)
    - Don't flush while the dec loop is working (LP: #1364466)
 -- Ricardo Salveti de Araujo <email address hidden> Mon, 08 Dec 2014 23:51:57 -0200