Bug 174080 - Applications crash playing a .wav file
Applications crash playing a .wav file
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: audiofile (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Monty
David Lawrence
:
Depends On:
Blocks: 181409
  Show dependency treegraph
 
Reported: 2005-11-24 06:15 EST by Bastien Nocera
Modified: 2013-10-20 18:41 EDT (History)
4 users (show)

See Also:
Fixed In Version: RHBA-2006-0583
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-10 17:48:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
audiofile-framecount.patch (1.13 KB, patch)
2005-11-24 06:15 EST, Bastien Nocera
no flags Details | Diff
laser.wav (8.25 KB, application/octet-stream)
2005-11-24 06:16 EST, Bastien Nocera
no flags Details

  None (edit)
Description Bastien Nocera 2005-11-24 06:15:33 EST
audiofile-0.2.6-1

audiofile crashes playing the attached .wav file (and it would crash Evolution
if that file was used as an alert for example). Patch attached.

patch from Brad Hinson <bhinson@redhat.com>
Comment 1 Bastien Nocera 2005-11-24 06:15:33 EST
Created attachment 121445 [details]
audiofile-framecount.patch
Comment 2 Bastien Nocera 2005-11-24 06:16:31 EST
Created attachment 121446 [details]
laser.wav
Comment 11 Monty 2006-06-08 18:34:47 EDT
Hello,

First off, the WAV file is corrupt, or at least nonstandard.  I'm interested to
know where you found it (or what produced it).

The second half of the included patch (ignore the fact chunk in uncompressed
data) looks safe enough.  The first part, however, is certainly incorrect (and
irrelevant to your prolem AFAICT) however I'm interested to know what the
rationale behind it is.  As far as I know, the only 'fact' chunk format
libaudiofile has a chance of supporting is the 'single word contents indicating
uncompressed file size as le32', which is the way it is pre-patch.  I'm unaware
of any other documented possibilities.

The second worry is that libaudiofile (or perhaps some of the Evo code using it)
is simply dealing badly with a wav file that's a different length than it
declares; this is not an uncommon occurence and if that too crashes Evo, it's
not libaudiofile's fault.

Summry:  Patch part two is good; patch part one is not, but I'd like to know
what it's trying to accomplish before acting.  There is also concern that this
fix will simply mask the real problem in the code using the library.

Monty
Comment 15 Brad Hinson 2006-06-29 15:29:31 EDT
Reposting response to comment 11 (it was lost in the BZ outage):
---

These wav files are included with OpenOffice
(/usr/lib/ooo-1.1/share/gallery/sounds/).  I do not believe they are corrupt,
rather, they use an optional Fact chunk.  Since libaudiofile isn't checking for
a fact chunk, it's reading garbage for the frame count, which confuses anyone
trying to play the file.

I think fixing the wav files would be masking the problem, because any
uncompressed waveform is allowed to have a fact chunk.  We have to allow for it
instead of interpreting it as part of the next field, which happens to be
totalFrames.

Here's where I got info on the fact chunk:
http://www.sonicspot.com/guide/wavefiles.html#fact

I've tested this patch on wav files with and without a fact chunk, and the
results were good.  Frame count read was always valid, plus you can hear the
difference - When the frame count is garbage, esdplay /usr/lib/.../laser.wav 
(which uses libaudiofile) plays incorrectly.
Comment 16 Monty 2006-07-06 11:52:01 EDT
[reconstructing a response that was lost in the Bugzilla crash:]

The refecerence you site for the FACT chunk is correct and agrees both with the
original audiofile code and with the conclusion that the OOo WAV files are
corrupt.  I'm not sure why you've come to the opposite conclusion.

The patch you provided worked in your tests because you didn't try any
compressed files that have a FACT chunk, only uncompressed files.  The patch,
as-is, breaks the compressed case.

In any case, the second half of the patch is both reasonable and 'fixes' the
behavior with the WAVs you've pointed out.  I've applied it. *This does not
change the fact that those WAV files are corrupt.*

Comment 21 Red Hat Bugzilla 2006-08-10 17:48:49 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2006-0583.html

Note You need to log in before you can comment on or make changes to this bug.