Bug 155224 - Update sox from 12.17.6 to 12.17.7
Update sox from 12.17.6 to 12.17.7
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: sox (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Woerner
http://sox.sourceforge.net/
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-18 04:11 EDT by Matthias Saou
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-26 21:08:52 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)
SMP overrun fix (1.50 KB, patch)
2005-04-26 03:44 EDT, Chris Bagwell
no flags Details | Diff

  None (edit)
Description Matthias Saou 2005-04-18 04:11:50 EDT
Current Fedora Core Development sox version is 12.17.6, but there is a new
upstream version since December, 12.17.7, with only bugfixes it seems (some
interesting ALSA ones too). See the "Latest News" section of the home page at
the URL above.
Comment 1 Matthias Saou 2005-04-18 04:14:42 EDT
Another related suggestion : The current package doesn't have "BuildRequires:
alsa-lib-devel", thus the ALSA driver isn't enabled when rebuilding in a minimal
root (the OSS driver is) :

Old Rate enabled..................   no
Fast ulaw enabled.................   yes
Fast alaw enabled.................   yes
GSM Support.......................   yes
ALSA Driver.......................   no
OSS Driver........................   yes
SUN /dev/audio....................   no
Ogg Vorbis support................   yes
MAD MP3 Decoder...................   no
LAME MP3 Encoder..................   no

It should probably be added.
Comment 2 Warren Togami 2005-04-18 04:30:39 EDT
thanks dude
Comment 3 Warren Togami 2005-04-18 04:42:19 EDT
REOPENING due to gcc detecting a buffer overflow.  Matthias, could you please
fix this, test it in runtime and submit a patch?

/mnt/redhat/beehive/logs/sox-555945-i386-decompose.build.redhat.com.log:smp.c:133:
warning: call to __builtin___strcpy_chk will always overflow destination buffer

<arjan>         char name[10];          /* Ascii Marker name */
<arjan>         uint32_t position;      /* Sample Number, not byte number */
<arjan> };
<arjan>         for(i = 0; i < 8; i++) {        /* write the 8 markers */
<arjan>                 strcpy(trailer->markers[i].name, "          ");
<arjan>                 trailer->markers[i].position = ~0;
<arjan>         }
<arjan> so the strcpy writes 11 bytes in a 10 byte array
<warren> arjan, will that struct automatically add padding for alignment or
it'll overwrite the uint32_t?
<arjan> hmm not sure; probably pads
<arjan> still it's broken code
<warren> yup
<warren> arjan, old version had the same problem
<arjan> still this code shouldn't be allowed to live.
<arjan> (and fwiw gcc has turned the strcpy() into an abort() )
Comment 4 Matthias Saou 2005-04-25 05:03:13 EDT
I've sent an email to the current sox maintainer to ask for a quick patch to
solve this problem.

About the other changes : The ALSA detection seems to use the kernel headers,
and not alsa-lib-devel... so I'm not sure what should be done here. Is this a
bug, and applications should only use alsa-lib? Should kernel-devel be added to
the build requirements? I don't even think this last solution would be correct,
as the build seems to look for the kernel headers for the running kernel (which
may fail in a build root with a different kernel package installed).
Comment 5 Chris Bagwell 2005-04-26 03:44:05 EDT
Created attachment 113660 [details]
SMP overrun fix

I'm upstream developer of SoX.	I'm out of the country for a couple of weeks
but here is how I will fix it when I have time.  Feel free to apply the patch
if your in hurry (ie. core 4).
Comment 6 Chris Bagwell 2005-04-26 03:54:15 EDT
I'm interested in feedback on ALSA drivers in Fedora/Redhat.  The original
author of the ALSA driver in SoX doesn't like the alsa-lib's since for most
usages they are no more then thin wrapper around kernel headers.

I'm pretty neutral on how to access ALSA drivers.  Up until Fedora starting
including ALSA, it wasn't important to me. :-)

Now that I use ALSA drivers, I've been adding patches to improve its quality in
SoX (see SoX 12.17.7 Changelog).  

The whole topic of using ALSA kernel headers seems to be murky... Plus there is
the major issue with ALSA's kernel headers using __user and __kernel macro's but
the standard "linux/compiler.h" header doesn't yet include those #defines (or
will it ever?).

Fedora may wish to make a policy that ALSA drivers are only turned on in
applications if they use alsa-lib.

Comment 7 Warren Togami 2005-04-26 21:08:52 EDT
The patch in Comment #5 is applied to FC4.  So closing this bug.

Comment 8 Matthias Saou 2005-04-27 04:37:01 EDT
Great, thanks Warren.
Chris : You're right, as I really think the proper way to detect and use ALSA
would be by using alsa-lib. With the current detection, when I rebuilt sox in a
chroot where only a Fedora Core Development kernel is present, the sox configure
script can't find the kernel headers for the `uname -r` kernel, since it's the
older one from the main host machine. So I'd say go ahead and try to switch to
something cleaner for the next sox release ;-)
Comment 9 Warren Togami 2005-04-27 04:40:08 EDT
Now that I think about it, I agree that alsa-lib should be used whenever
possible.  Userspace apps should avoid kernel interfaces whenever possible, and
alsa-lib is the designated abstraction.

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