Bugzilla Bug 58780

This applies to all versions of faad2 in portage as of this date.  (except 1.1
which will not compile).  When running the faad2 front end "faad" on the
command line decoding an aac file, many error messages are printed and the
application causes a segmentation fault when it quits.

Reproducible: Always
Steps to Reproduce:
1. Log on a AMD64 gentoo machine
2. emerge faad2
3. faad your_fav_aac.aac
4. Try playing your_fav_aac.aac in xmms using the faad2 plugin

Actual Results:  
Error: Pulse coding not allowed in short blocks
Error: Pulse coding not allowed in short blocks
Error: Pulse coding not allowed in short blocks
Segmentation fault

xmms faad2 plugin is non-functional

Expected Results:  
Decoding test.aac took:  1.89 sec. 58.52x real-time.
xmms faad2 plugin plays music

This bug is the result of faad2 using inconsistently sized data types.  This
(and a fix) is discussed here:
http://faac.sourceforge.net/phorum/read.php?f=1&i=4981&t=4981 .  Specifically,
the author assumes that long is a 32-bit value.

I have tested this fix and it works.  The faad front end now correctly decodes
aac files and the xmms plugin works.  But, the segmentation fault still
remains.  Running in gdb, the segmentation fault occurs in a call to free()
called by faadDecClose().  

A post here: http://faac.sourceforge.net/phorum/read.php?f=1&i=4940&t=4940
claims to fix the segmentation fault.  I have tried it and it does not.  Upon
examining the change, an in32 is changed to a size_t in the argument to malloc.
 This would only make a difference if faad was mallocing over 2GB, which is not
the case.

Segmentation faults in free() are usually indications of heap corruption.   My
guess is that there are other inconsistent data types in libfaad.

could you give me a backtrace of the segfault that occurs?

#0  0x00000038cf56a799 in mallopt () from /lib/libc.so.6
#1  0x00000038cf5693fa in free () from /lib/libc.so.6
#2  0x00000038cfe1c06b in faad_free (b=0x509290) at common.c:249
#3  0x00000038cfe0a965 in drc_end (drc=0x509290) at drc.c:54
#4  0x00000038cfe09a3e in faacDecClose (hDecoder=0x508510) at decoder.c:500
#5  0x000000000040240a in decodeAACfile (aacfile=0x7fbffff190 "01_Track01.aac",
    sndfile=0x7fbffff090 "01_Track01.wav", adts_fn=0x0, to_stdout=0, def_srate=0,
    object_type=-1073746352, outputFormat=1, fileType=1, downMatrix=80, infoOnly=0,
    adts_out=0, old_format=0, song_length=0x50) at main.c:632
#6  0x0000000000403693 in main (argc=-1073745520, argv=0x0) at main.c:1210

I have noticed that the faac forums have changed.  Consequently, the links in
the initial bug report no longer work.

The change referenced was a header file used to compile libfaad which uses some
different sized data types than the one software using libfaad compiles with.

The header file is faad2/libfaad/structs.h

Here is a diff of the modifications I made to get faad2 to work as I describe
above.

diff faad2/libfaad/structs.h ~/faad2_works/libfaad/structs.h
341,342c341,342
<     uint32_t bytesconsumed;
<     uint32_t samples;
---
>     unsigned long bytesconsumed;
>     unsigned long samples;
345c345
<     uint32_t samplerate;
---
>     unsigned long samplerate;

I also examined the FAAD2-2.0 source from www.audiocoding.com dated 2004/8/14
and it includes the changes I made (presumably other changes too).

Perhaps if the faad2 ebuild was used on the latest source release from
audiocoding.com, everything would work.

I finally got around to trying the updated code i mentioned.  
Downloaded the FAAD2-2.0 source from www.audiocoding.com dated 2004/8/14, ran configure and make without modifying any code or applying any patches.

The resulting faad2 frontend and xmms plugin run flawlessly. I.e. there is no segfault as I encountered with the source modifications I made to the old FAAD2-2.0 release.

A new ebuild should be created that uses the most current faad2-2.0 source. And it will actually work!  Unlike all the currently marked "STABLE" faad2's that don't work at all.

Have tried downloading and compiling the latest sources, but the arrangement
seems a touch more complicated than compile and make....at least for this
portage-spoiled luser.

A revised ebuild would be greatly appreciated.  :-)

I would gladly try writing an ebuild. However, in my attemt to do this, i have
discovered something strange.  

The faad2-2.0.tar.gz that I downloaded from a sourceforge mirror link at
www.audiocoding.com on 2004-9-16 (the audiocoding.com link said "Submitted:
2004-8-14) is now DIFFERENT than the one that can be downloaded now.  The
audiocoding.com download link now reads "Submitted: 2004/8/15".  

Obviously, something fishy is going on with the dates.  Consequently, the one
that can be downloaded now is the same as the faad2-2.0.tar.gz on the gentoo
distfiles mirrors. 

So, was I not paying attention and downloaded the CVS snapshot?  I might have,
but doubt it. Things got fishier when i attempted to determine which version I
actually have.

A recursive diff of the two directories shows a few additional files in the
"2004-8-14" version.  There are also numerous changes in many of the source
files (that apparently fix the bugs on amd64).  However, I compared the CVS
$Id: strings on all the files in the two versions.  And they ALL match exactly. 

So, I am at a loss. I would write an ebuild, but I am the only one with the
source tarball.  And I cant even determine what date/version the code I do have
is, so getting this exact version from CVS is impossible.

My current theory is that someone messed up and posted the wrong file (possibly
a modified version that had yet to be commited to CVS) as faad2-2.0.tar.gz and
reverted the mistake.  However, I can find no mention of this in the news or
forums at www.audiocoding.com.  

This bug may simply have to wait until a new version of faad2 is properly
released.  I suggest to anyone on amd64 wishing a working mp4 player to try the
latest CVS snapshot from www.audiocoding.com.  The "current" version needs
patches just to ./configure in gentoo, but the current versions in CVS appear
to have fixed that issue.  Just do "autoreconf -vif" first like the
README.linux says.

Hm.  A few further observations, which may prove useful to some:

Gentoo's autoconf package (v. 2.59-r4) installs both autoreconf 2-13 and autoreconf 2.59, as well as a perl script to handle execution of just plain "autoreconf."  On my system, the perl script seems to invoke v2.13, which doesn't do the compilation.  I had to explicitly run v2.59 to get the thing to compile.

Even after that hiccup, I ran into further difficulties in compiling.  Something about static linkages and mp4ff.  Adding -fPIC to CFLAGS (as make itself requested) got it to compile.  

And yay!  It appears to be working.

I've posted a link to this bug report in the audiocoding.com forums.  I hope that if I'm not much good at actually fixing things, I can at least help to get the people who can fix them communicating.

Ok, i apoligize for any confusion my earlier post about the faad2-2.0.tar.gz
file on www.audiocoding.com changing.  It most likely did not change.  The
reason the files in it were modified is because I modified them and repackaged
it under the same name (silly me).

Anyways, this means that I have a working patch with the modifications to the
code mentioned in Additional Comment #1, but without the seg fault.  My only
hypothesis is that the seg fault went away because a glibc, compiler, or some
other system update.

Created an attachment (id=40188) [details]
Patch to get faad2 working under amd64

An ebuild that uses this patch is coming soon...

Created an attachment (id=40239) [details]
ebuild for faad2

I ran into some problems creating this ebuild.	

(1) the xmms plugin whouldn't build correctly.	It doesn't even build witht the
faad2 ebuilds in portage!  I don't know what caused this problem.  I managed to
fix it with a dirty hack which patches the generated makefile in
faad2/plugins/xmms/src

The line LIBS = "-lmp4v2 -lmp4v2" is changed to "LIBS = " (since the mp4v2 is
linked in by another part of the Makefile)

(2) The seg fault is back.  It seems to be related to CFLAGS, and I recommend
compiling with -g only. But, sometimes it seg faults and other times not.  So,
clearly there are still some issues here.

---
This ebuild is a dirty hack, and I don't think it should be added to portage. 
If and when the goofy -lmp4v2 thing witht the generated makefile is fixed (it
used to work fine, and this line causes no problems on my x86 system) the
"hack" can be removed from this ebuild.  But, the seg fault will still exist.

I have tested the 15-9-2004 CVS snapshot from www.audiocoding.com. After adding
a missing -fPIC, it compiles and runs without any problems. Perhaps a cvs
ebuild is in order?

In any case, I doubt that a stable faad2 will be possible on amd64 until the
next version is released.  Funny though, that it is still marked stable in
portage.

faad-2.0-r3 is stable on amd64, which should have fixed this bug. i can't test
it though since i don't have a aac file, so please reopen if this is still an
issue

I cannot decode (play) any aac or mp4 files through XMMS with faad2 still.

I've got an amd64 2800+ on an ASUS K8V motherboard.

If you need more information, please let me know.  I'm not a developer, but am very active in the Linux community.

oh... also, I'm using faad2-2.0-r3 on Gentoo.

I've the version 2.0-r4 installed and I still can't play AAC files with mplayer
:

FAAD: Failed to decode frame: Pulse coding not allowed in short blocks

Boris.

Using
media-libs/faad2
Latest version available: 2.0-r6
Latest version installed: 2.0-r6

$ faac file.m4a

I get:
Warning: Pulse coding not allowed in short blocks (repeated ad nauseum)
*** glibc detected *** double free or corruption (out): 0x00000000005080b0 ***
Aborted

Same result for 2.0-r4 from the emerge tree.