libmad causes mpd to seg fault on update

Bug #989846 reported by limaxray on 2012-04-27
This bug affects 12 people
Affects Status Importance Assigned to Milestone
libmad (Debian)
libmad (Ubuntu)

Bug Description

This is an 12.04 armhf install on a B7 BeagleBoard.

mpd version is 0.16.5-1ubuntu4
libmad version is 0.15.1b-7ubuntu1

What happens: mpd will start and allow local and remote clients to connect as expected. Requesting a database update with an attached client (ie 'mpc update') causes mpd to crash. Attaching gdb reveals seg fault occurs in call to libmad.

What should happen: Database should update and mpd should continue to run.

Installing armhf build of libmad0 (0.15.1b-7) from Debian Wheeze solves the problem.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: libmad0 0.15.1b-7ubuntu1
Uname: Linux 3.2.16-x10 armv7l
ApportVersion: 2.0.1-0ubuntu6
Architecture: armhf
Date: Fri Apr 27 11:27:03 2012
SourcePackage: libmad
UpgradeStatus: No upgrade log present (probably fresh install)

limaxray (matt-limaxray) wrote :
Launchpad Janitor (janitor) wrote :

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

Changed in libmad (Ubuntu):
status: New → Confirmed
Torsten Harenberg (harenberg) wrote :

Same behavior seen on a Pandaboard.

Torsten Harenberg (harenberg) wrote :

Output from gdb trying to play and mp3 file with herrie (

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xad1fe3f0 (LWP 26380)]
0xb6d42760 in mad_layer_III () from /usr/lib/arm-linux-gnueabihf/
(gdb) bt
#0 0xb6d42760 in mad_layer_III () from /usr/lib/arm-linux-gnueabihf/
#1 0x00f4dd96 in ?? ()
#2 0x00f4dd96 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) quit
A debugging session is active.

        Inferior 1 [process 26375] will be killed.

Leon (leonbo) wrote :

Pandaboard + mpd:

root@panda:~# gdb mpd 2>&1 | tee ~/gdb-mpd.txt
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
For bug reporting instructions, please see:
Reading symbols from /usr/bin/mpd...(no debugging symbols found)...done.
(gdb) handle SIG33 pass nostop noprint
Signal Stop Print Pass to program Description
SIG33 No No Yes Real-time event 33
(gdb) set pagination 0
(gdb) run --no-daemon /etc/mpd.conf
Starting program: /usr/bin/mpd --no-daemon /etc/mpd.conf
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/".
[New Thread 0xb4eb0440 (LWP 28658)]
[New Thread 0xb44ff440 (LWP 28659)]
[New Thread 0xb38ff440 (LWP 28660)]
[New Thread 0xb2eff440 (LWP 28661)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb2eff440 (LWP 28661)]
0xb6011760 in mad_layer_III () from /usr/lib/arm-linux-gnueabihf/

Fabian (maystar) wrote :

I can confirm this bug in Kubuntu on pandaboard, too

Tyler Hall (tylerwhall) wrote :

Single-stepping in gdb revealed that things fell apart after calling III_imdct_l(). The ARM-specific implementation is in imdct_l_arm.S. Possibly a hardfp ABI incompatibility? Running configure with "--disable-aso" works around it.

abw (arminwagner2008) wrote :

I'm using a 12.04 Ubuntu armhf install on a Beaglebone and mpg321 is segfaulting.
Compiling libmad myself helped. Here are some notes:

Changed in libmad (Debian):
status: Unknown → New
Thomas Pilarski (thomas.pi) wrote :

I can confirm the workaround from comment #7 - I build the package and added to --disable-aso to the debian/rules files and everything works file.

Iain Lane (laney) wrote :

Indeed, it seems to be a problem in the architecture specific optimisation for ARM.

(gdb) s
_III_imdct_l () at imdct_l_arm.S:213
213 stmdb sp!, { r2, r4 - r11, lr } @ all callee saved regs, plus arg3
(gdb) s
Cannot access memory at address 0xfb30506a
(gdb) s

Program received signal SIGSEGV, Segmentation fault.
0x40107b12 in mad_layer_III (stream=<error reading variable: Cannot access memory at address 0xfb304f22>,
    frame=<error reading variable: Cannot access memory at address 0xfb304f1e>) at layer3.c:2560
2560 if (header->flags & MAD_FLAG_PROTECTION) {

I think for now I'll disable the ASO on arm. The assembler there is quite old, from 2001 according to copyright. If someone wants to update it they are more than welcome.

This bug causes rhythmbox to crash on ARM (e.g. Nexus 7) when gstreamer1.0-plugins-ugly (which links to libmad0) is installed.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libmad - 0.15.1b-7ubuntu2

libmad (0.15.1b-7ubuntu2) raring; urgency=low

  * Disable architecture specific optimisations on ARM, as there is a bug in
    this codepath which causes segfaults, and the assembler is very old
    (likely bitrotted). (LP: #989846)
 -- Iain Lane <email address hidden> Wed, 12 Dec 2012 12:10:33 +0000

Changed in libmad (Ubuntu):
status: Confirmed → Fix Released
Ivan Zakharyaschev (imz) wrote :

What about putting the fix into the repos for 12.04 LTS?

Without this, most video players don't work on ARM machines. :(

Ivan Zakharyaschev (imz) wrote :

What about putting the fix into the repos for 12.04 LTS?

Please, someone, nominate it for 12.04.


Without this, most video players don't work on ARM machines. :(

[Test Case]

From :

mpg321 /usr/share/libubuntuoneui/1/javascript/empty.mp3

should not crash on ARM.

[Regression Potential]

The fix removes some optimizations. No regressions are expected.

Oliver Grawert (ogra) wrote :
Ivan Zakharyaschev (imz) wrote :

Does --disable-aso (which fixes the problem) disable soemthing in the compiler tools, or this just disables some written beforehand assembler code which is supposed to work better?

If the bugs comes from the code generated by the compiler tools with soem optimizations on, shouldn't we report this to the compiler developers?

Rolf Leggewie (r0lf) wrote :

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

Changed in libmad (Ubuntu Quantal):
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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