Bug 174080 - Applications crash playing a .wav file
Summary: Applications crash playing a .wav file
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: audiofile
Version: 4.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Monty
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks: 181409
TreeView+ depends on / blocked
 
Reported: 2005-11-24 11:15 UTC by Bastien Nocera
Modified: 2013-10-20 22:41 UTC (History)
4 users (show)

Fixed In Version: RHBA-2006-0583
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-08-10 21:48:49 UTC
Target Upstream Version:
Embargoed:


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


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2006:0583 0 normal SHIPPED_LIVE audiofile bug fix update 2006-08-10 04:00:00 UTC

Description Bastien Nocera 2005-11-24 11:15:33 UTC
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>

Comment 1 Bastien Nocera 2005-11-24 11:15:33 UTC
Created attachment 121445 [details]
audiofile-framecount.patch

Comment 2 Bastien Nocera 2005-11-24 11:16:31 UTC
Created attachment 121446 [details]
laser.wav

Comment 11 Monty 2006-06-08 22:34:47 UTC
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 19:29:31 UTC
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 15:52:01 UTC
[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 21:48:49 UTC
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.