mediascanner-service-2.0 crashed with SIGSEGV

[Dave Morley]

STEPS:
1. Plug a mako into a pc
2. Open a terminal
3. adb reboot bootloader
4. ubuntu-device-flash --channel devel-proposed --device mako --bootstrap
5. Wait for it to finish
6. Transfer over 4.3GB of music
7. Transfer over Some videos
8. Unlock the phone
9. Flick between the scopes
10 Crash.

ProblemType: Crash
DistroRelease: Ubuntu 14.04
Package: mediascanner2.0 0.100+14.04.20140324-0ubuntu1
Uname: Linux 3.4.0-5-mako armv7l
ApportVersion: 2.13.3-0ubuntu1
Architecture: armhf
CurrentDesktop: Unity
Date: Fri Mar 28 10:49:29 2014
ExecutablePath: /usr/bin/mediascanner-service-2.0
InstallationDate: Installed on 2014-03-28 (0 days ago)
InstallationMedia: Ubuntu Trusty Tahr (development branch) - armhf (20140328)
ProcCmdline: mediascanner-service-2.0
Signal: 11
SourcePackage: mediascanner2
Stacktrace:
 #0 0xb6b58b52 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
 No symbol table info available.
 #1 0xb6b59374 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
 No symbol table info available.
 Backtrace stopped: previous frame identical to this frame (corrupt stack?)
StacktraceTop:
 ?? () from /lib/arm-linux-gnueabihf/libc.so.6
 ?? () from /lib/arm-linux-gnueabihf/libc.so.6
Title: mediascanner-service-2.0 crashed with SIGSEGV
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm autopilot cdrom dialout dip nopasswdlogin plugdev sudo tty video

[Apport retracing service (apport)]

StacktraceTop:
 malloc_consolidate () at malloc.c:4165
 _int_free () at malloc.c:4057
 array_free () from /tmp/apport_sandbox_jjzwvm/lib/arm-linux-gnueabihf/libglib-2.0.so.0
 gst_structure_free () from /tmp/apport_sandbox_jjzwvm/usr/lib/arm-linux-gnueabihf/libgstreamer-1.0.so.0
 _gst_caps_free () from /tmp/apport_sandbox_jjzwvm/usr/lib/arm-linux-gnueabihf/libgstreamer-1.0.so.0

[Jussi Pakkanen (jpakkane)]

The stack trace implies that gstreamer has corrupted its memory state somehow. A probable cause is that you have a media file that triggers a bug in either gstreamer or the plugins it uses (and probably only on ARM, too). Would it be possible for you to try to narrow down which file is causing this issue.

If you know your way around the shell, one way is to install the package gstreamer1.0-plugins-base-apps and then run gst-discoverer-1.0 <target file> on every file in your music and video directories.

Another, slightly cruder way, is to clear your device of all video files, and then copy them on the device in batches (such as one subdirectory at a time). Have pauses between each batch so the system has time to analyze the files before copying in new files. Eventually you should hit the crashing directory and from there on to the actual file.

Thanks

[Dave Morley (davmor2)]

After recent changes have landed I am no longer able to reproduce this issue so am marking it invalid

[James Henstridge (jamesh)]

Once it gets through CI Train, there should be an additional log message before the daemon tries to extract metadata from a file. This should help in pinpointing what file it was having trouble with.

That said, it's been difficult to find a single file that will reliably trigger the bug, which makes things a bit more difficult.