mediaplayer-app crashed with SIGABRT in __gconv_release_step()

Bug #1239289 reported by Jean-Baptiste Lallement
18
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gst-plugins-bad1.0 (Ubuntu)
New
Undecided
Unassigned
Saucy
Won't Fix
Undecided
Unassigned
mediaplayer-app (Ubuntu)
Confirmed
Critical
Jim Hodapp
Saucy
Won't Fix
Critical
Jim Hodapp

Bug Description

mediaplayer-app crashed on second video I played from the file browser.

TEST CASE:
1. Upload 2 videos to the folder 'Videos' of the device
2. Open file manager and go 'Videos' or go to the video lens
3. Open the 1rst video
4. Switch back to the file browser or lens
5. Open the second video

EXPECTED RESULT
player starts stops first video and starts playing second one.

ACTUAL RESULT
second video doesn't start and player crash.

ProblemType: Crash
DistroRelease: Ubuntu 13.10
Package: mediaplayer-app 0.20.5+13.10.20131007-0ubuntu1
Uname: Linux 3.4.0-3-mako armv7l
ApportVersion: 2.12.5-0ubuntu2
Architecture: armhf
Date: Sun Oct 13 09:49:52 2013
ExecutablePath: /usr/bin/mediaplayer-app
ExecutableTimestamp: 1381181954
InstallationDate: Installed on 2013-10-12 (1 days ago)
InstallationMedia: Ubuntu Saucy Salamander (development branch) - armhf (20131012)
MarkForUpload: True
ProcCmdline: mediaplayer-app file:///home/phablet/Videos/Blade%20Runner%20Final%20Cut.avi
ProcCwd: /home/phablet
Signal: 6
SourcePackage: mediaplayer-app
StacktraceTop:
 ?? () from /lib/arm-linux-gnueabihf/libc.so.6
 raise () from /lib/arm-linux-gnueabihf/libc.so.6
 abort () from /lib/arm-linux-gnueabihf/libc.so.6
 ?? ()
 ?? ()
Title: mediaplayer-app crashed with SIGABRT in raise()
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm autopilot cdrom dialout dip nopasswdlogin plugdev sudo tty video

Revision history for this message
Jean-Baptiste Lallement (jibel) wrote :
Revision history for this message
Apport retracing service (apport) wrote :

StacktraceSource:
 #0 0x40ebc706 in __gconv_release_step (step=0x5a75f920) at gconv_db.c:235
   [Error: gconv_db.c was not found in source tree]
 #1 0x40ecce1a in __new_exitfn (listp=0x4563ad80) at cxa_atexit.c:78
   [Error: cxa_atexit.c was not found in source tree]
 #2 0x00000000 in ?? ()
StacktraceTop:
 __gconv_release_step (step=0x5a75f920) at gconv_db.c:235
 __new_exitfn (listp=0x4563ad80) at cxa_atexit.c:78
 ?? ()

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 mediaplayer-app (Ubuntu):
importance: Undecided → Medium
summary: - mediaplayer-app crashed with SIGABRT in raise()
+ mediaplayer-app crashed with SIGABRT in __gconv_release_step()
tags: removed: need-armhf-retrace
Changed in mediaplayer-app (Ubuntu):
importance: Medium → Critical
tags: added: rls-s-incoming
description: updated
tags: added: testcase
description: updated
Revision history for this message
Olivier Tilloy (osomon) wrote :

The attached ThreadStacktrace is incomplete, it only has threads 29 through 33.

Revision history for this message
Jean-Baptiste Lallement (jibel) wrote :

I couldn't produce a better trace. The test case is trivial, have you been able to reproduce and maybe produce a better trace than I did?

Revision history for this message
Olivier Tilloy (osomon) wrote :

I can reproduce on maguro.

Changed in mediaplayer-app (Ubuntu Saucy):
status: New → Confirmed
Revision history for this message
Olivier Tilloy (osomon) wrote :

I can reproduce 100% of the times, but I never get the same stacktrace twice. I’m digging further.

Changed in mediaplayer-app (Ubuntu Saucy):
assignee: nobody → Olivier Tilloy (osomon)
Revision history for this message
Olivier Tilloy (osomon) wrote :

I can still reproduce the crash but for some reason when apport finishes writing the crash file it truncates it to 103K, and when unpacking it it doesn’t contain a CoreDump anymore. Reproduced the crash several times, rebooted several times in between, and I’m always getting this crash file without a core dump.

Revision history for this message
Olivier Tilloy (osomon) wrote :

In my attempts to understand where the crash happens, I have modified the onOpened handler in /usr/share/mediaplayer-app/qml/player.qml to stop the playback and unset the source before enqueuing the new URIs, but this doesn’t make any difference, the crash still happens:

    Connections {
        target: UriHandler
        onOpened: {
            playerLoader.item.stop()
            playerLoader.item.source = ""
            for (var i = 0; i < uris.length; ++i) {
                playerLoader.item.playUri(uris[i])
            }
        }
    }

Revision history for this message
Olivier Tilloy (osomon) wrote :

I’m attaching a more complete stacktrace.

I talked to Renato, and he suggested it might be a codec issue.

Revision history for this message
Olivier Tilloy (osomon) wrote :
Revision history for this message
Olivier Tilloy (osomon) wrote :

Renato suggested I remove gstreamer1.0-hybris and try and reproduce the issue.
I didn’t remove the package itself as ubuntu-touch depends on it, however I renamed the two libs it ships to ensure they’re not loaded, and I can confirm I cannot reproduce the issue anymore, so it appears it’s a codec issue indeed.

Olivier Tilloy (osomon)
Changed in mediaplayer-app (Ubuntu Saucy):
assignee: Olivier Tilloy (osomon) → nobody
Changed in mediaplayer-app (Ubuntu Saucy):
assignee: nobody → Jim Hodapp (jhodapp)
Revision history for this message
Rolf Leggewie (r0lf) wrote :

saucy has seen the end of its life and is no longer receiving any updates. Marking the saucy task for this ticket as "Won't Fix".

Changed in mediaplayer-app (Ubuntu Saucy):
status: Confirmed → Won't Fix
Rolf Leggewie (r0lf)
Changed in gst-plugins-bad1.0 (Ubuntu Saucy):
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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