* [ALSA - tools 0001343]: bitops not 64bit clean
@ 2005-08-17 10:23 bugtrack
0 siblings, 0 replies; 7+ messages in thread
From: bugtrack @ 2005-08-17 10:23 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1343>
======================================================================
Reported By: jdthood
Assigned To:
======================================================================
Project: ALSA - tools
Issue ID: 1343
Category: ld10k1
Reproducibility: always
Severity: major
Priority: normal
Status: new
======================================================================
Date Submitted: 08-16-2005 20:49 CEST
Last Modified: 08-17-2005 12:23 CEST
======================================================================
Summary: bitops not 64bit clean
Description:
Quoting Debian bug report #323331:
Package: ld10k1
Version: 1.0.9-1
On all 64bit systems (the easiest example is amd64) ld10k1 crashes on
use by lo10k1, some debugging tracked down the problem fairly quickly.
The bitops functions (set_bit and associated) that ld10k1 use come from
the linux kernel, and assume that longs are 32bit only, causing a buffer
overflow of the bit buffer.
The attached patch fixes the bitops to be independent of the size of
longs, and is confirmed to fix the bug on my box.
Zephaniah E. Hull.
diff -ur alsa-tools-1.0.9/ld10k1/src/bitops.h
alsa-tools-1.0.9.mine/ld10k1/src/bitops.h
--- alsa-tools-1.0.9/ld10k1/src/bitops.h 2005-03-18 08:41:02.000000000
-0500
+++ alsa-tools-1.0.9.mine/ld10k1/src/bitops.h 2005-08-15
23:24:46.000000000 -0400
@@ -15,13 +15,17 @@
*
* C language equivalents written by Theodore Ts'o, 9/26/92
*/
+/*
+ * Converted to be independent of the size of longs.
+ * Zephaniah E. Hull 2005-08-15.
+ */
__inline__ int set_bit(int nr, unsigned long * addr)
{
int mask, retval;
- addr += nr >> 5;
- mask = 1 << (nr & 0x1f);
+ addr += nr >> (sizeof(long) + 1);
+ mask = 1 << (nr & (sizeof(long) * 8 - 1));
retval = (mask & *addr) != 0;
*addr |= mask;
return retval;
@@ -31,8 +35,8 @@
{
int mask, retval;
- addr += nr >> 5;
- mask = 1 << (nr & 0x1f);
+ addr += nr >> (sizeof(long) + 1);
+ mask = 1 << (nr & (sizeof(long) * 8 - 1));
retval = (mask & *addr) != 0;
*addr &= ~mask;
return retval;
@@ -42,8 +46,8 @@
{
int mask;
- addr += nr >> 5;
- mask = 1 << (nr & 0x1f);
+ addr += nr >> (sizeof(long) + 1);
+ mask = 1 << (nr & (sizeof(long) * 8 - 1));
return ((mask & *addr) != 0);
}
======================================================================
----------------------------------------------------------------------
pzad - 08-16-05 21:13
----------------------------------------------------------------------
This is used to set used (valid) GPRs, TRAM, code maps in CODE_POKE ioctl.
----------------------------------------------------------------------
tiwai - 08-17-05 12:23
----------------------------------------------------------------------
Could you upload the patch file to be applicable to CVS?
Issue History
Date Modified Username Field Change
======================================================================
08-16-05 20:49 jdthood New Issue
08-16-05 20:52 rlrevell Note Added: 0005832
08-16-05 21:13 pzad Note Added: 0005833
08-17-05 12:23 tiwai Note Added: 0005836
======================================================================
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 7+ messages in thread* [ALSA - tools 0001343]: bitops not 64bit clean
@ 2005-08-26 12:42 bugtrack
2005-11-06 22:56 ` D. Hugh Redelmeier
0 siblings, 1 reply; 7+ messages in thread
From: bugtrack @ 2005-08-26 12:42 UTC (permalink / raw)
To: alsa-devel
The following issue has been RESOLVED.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1343>
======================================================================
Reported By: jdthood
Assigned To: tiwai
======================================================================
Project: ALSA - tools
Issue ID: 1343
Category: ld10k1
Reproducibility: always
Severity: major
Priority: normal
Status: resolved
Resolution: fixed
Fixed in Version:
======================================================================
Date Submitted: 08-16-2005 20:49 CEST
Last Modified: 08-26-2005 14:42 CEST
======================================================================
Summary: bitops not 64bit clean
Description:
Quoting Debian bug report #323331:
Package: ld10k1
Version: 1.0.9-1
On all 64bit systems (the easiest example is amd64) ld10k1 crashes on
use by lo10k1, some debugging tracked down the problem fairly quickly.
The bitops functions (set_bit and associated) that ld10k1 use come from
the linux kernel, and assume that longs are 32bit only, causing a buffer
overflow of the bit buffer.
The attached patch fixes the bitops to be independent of the size of
longs, and is confirmed to fix the bug on my box.
Zephaniah E. Hull.
diff -ur alsa-tools-1.0.9/ld10k1/src/bitops.h
alsa-tools-1.0.9.mine/ld10k1/src/bitops.h
--- alsa-tools-1.0.9/ld10k1/src/bitops.h 2005-03-18 08:41:02.000000000
-0500
+++ alsa-tools-1.0.9.mine/ld10k1/src/bitops.h 2005-08-15
23:24:46.000000000 -0400
@@ -15,13 +15,17 @@
*
* C language equivalents written by Theodore Ts'o, 9/26/92
*/
+/*
+ * Converted to be independent of the size of longs.
+ * Zephaniah E. Hull 2005-08-15.
+ */
__inline__ int set_bit(int nr, unsigned long * addr)
{
int mask, retval;
- addr += nr >> 5;
- mask = 1 << (nr & 0x1f);
+ addr += nr >> (sizeof(long) + 1);
+ mask = 1 << (nr & (sizeof(long) * 8 - 1));
retval = (mask & *addr) != 0;
*addr |= mask;
return retval;
@@ -31,8 +35,8 @@
{
int mask, retval;
- addr += nr >> 5;
- mask = 1 << (nr & 0x1f);
+ addr += nr >> (sizeof(long) + 1);
+ mask = 1 << (nr & (sizeof(long) * 8 - 1));
retval = (mask & *addr) != 0;
*addr &= ~mask;
return retval;
@@ -42,8 +46,8 @@
{
int mask;
- addr += nr >> 5;
- mask = 1 << (nr & 0x1f);
+ addr += nr >> (sizeof(long) + 1);
+ mask = 1 << (nr & (sizeof(long) * 8 - 1));
return ((mask & *addr) != 0);
}
======================================================================
----------------------------------------------------------------------
tiwai - 08-17-05 12:23
----------------------------------------------------------------------
Could you upload the patch file to be applicable to CVS?
----------------------------------------------------------------------
tiwai - 08-26-05 14:42
----------------------------------------------------------------------
Already on CVS. Thanks.
Issue History
Date Modified Username Field Change
======================================================================
08-16-05 20:49 jdthood New Issue
08-16-05 20:52 rlrevell Note Added: 0005832
08-16-05 21:13 pzad Note Added: 0005833
08-17-05 12:23 tiwai Note Added: 0005836
08-17-05 12:37 jdthood File Added: ld10k1.diff
08-26-05 14:42 tiwai Status new => resolved
08-26-05 14:42 tiwai Resolution open => fixed
08-26-05 14:42 tiwai Assigned To => tiwai
08-26-05 14:42 tiwai Note Added: 0005947
======================================================================
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [ALSA - tools 0001343]: bitops not 64bit clean
2005-08-26 12:42 bugtrack
@ 2005-11-06 22:56 ` D. Hugh Redelmeier
2005-11-08 17:14 ` Takashi Iwai
0 siblings, 1 reply; 7+ messages in thread
From: D. Hugh Redelmeier @ 2005-11-06 22:56 UTC (permalink / raw)
To: alsa-devel
| From: bugtrack@alsa-project.org
| Date: Fri, 26 Aug 2005 14:42:44 +0200
| The following issue has been RESOLVED.
| ======================================================================
| <https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1343>
| ======================================================================
| The bitops functions (set_bit and associated) that ld10k1 use come from
| the linux kernel, and assume that longs are 32bit only, causing a buffer
| overflow of the bit buffer.
|
| The attached patch fixes the bitops to be independent of the size of
| longs, and is confirmed to fix the bug on my box.
| diff -ur alsa-tools-1.0.9/ld10k1/src/bitops.h
| alsa-tools-1.0.9.mine/ld10k1/src/bitops.h
| --- alsa-tools-1.0.9/ld10k1/src/bitops.h 2005-03-18 08:41:02.000000000
| - addr += nr >> 5;
| - mask = 1 << (nr & 0x1f);
| + addr += nr >> (sizeof(long) + 1);
| + mask = 1 << (nr & (sizeof(long) * 8 - 1));
[A similar change appears two other places in the bitops.h.]
You cans see this in CVS:
http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-tools/ld10k1/src/bitops.h?rev=1.2&view=log
This patch looks very wrong to me. The original code used 5 because
it is the base 2 log of the number of bits in an unsigned long
(thought to be always 32) and 0x1f because it is a mask with the
length of that same 5.
When sizeof(unsigned long) == 4:
sizeof(long) + 1 == 5
and
log2(sizeof(unsigned long) * 8) == 5
so the new code should work in this case.
When sizeof(unsigned long) == 8
sizeof(long) + 1 == 9
and
log2(sizeof(unsigned long) * 8) == 6
so the new code should not work in this case.
If this code actually works on a system with sizeof(long) == 8, then
something very funny is going on.
I don't know anything about how these functions are used, so I cannot
say what the correct fix is.
As rlrevell said in the bugtrack entry, the right change might be to
use type u32 rather than long.
Alternatively, you need a way to reference log2(sizeof(long) * 8).
Perhaps this is in some header. It is kind of hard to calculate lg2
in a manifest constant expression.
UNTESTED CODE:
/* lg2_ulong_bits: log-base-2 of the number of bits in an unsigned long.
* Assumes:
* (1) a char is 8 bits (almost always true, but not required by C)
* (2) sizeof(unsigned long) is a power of two (almost always true; assumed
* by other parts of the code)
* (3) sizeof(unsigned long) is at least 4 (guaranteed by C and (1))
* (4) sizeof(unsigned long) is at most 32 (likely true for a long while)
*/
#define lg2_ulong_bits (5 + \
(sizeof(unsigned long) > 4) + \
(sizeof(unsigned long) > 8) + \
(sizeof(unsigned long) > 16))
| - addr += nr >> 5;
| - mask = 1 << (nr & 0x1f);
| + addr += nr >> lg2_ulong_bits;
| + mask = 1 << (nr & (sizeof(unsigned long) * 8 - 1));
There is a SECOND bug in this code. The mask is declared to be of
type int but should be of type unsigned long.
The assignment to mask is also wrong: the "1" being shifted should
actually be "1UL". Otherwise the shift is done with an int and will
get the wrong value if sizeof(int) != sizeof(unsigned long).
Technically, but not practically, an int overflow results in undefined
behavior, according to the C standard.
Similar changes are needed in the other *_bit functions.
NOTE: I am new to the internals to alsa. I only noticed this because
I just read the (old!) mail to which I am replying.
I did a quick look at the ld10k1/src directory in CVS. The first file
that referred to a *_bit function was dl10k1.c. It seems to include
<bitops.h>, not "bitops.h". Normally, this would be the system
header file (depending on the flags used to invoke the C compiler).
On my system, Fedora Core 4 on x86_64, there is no <bitops.h> but
there is an <asm/bitops.h>. So: I don't know what header would be
used.
The <asm/bitops.h> versions are atomic: they use lock prefixes.
Is this what ld10k1 wants? Most single-threaded userland code doesn't
need this. The code in "bitops.h" doesn't seem to be coded to be
atomic. If so, I think that the naming convention in the kernel should be
followed: use names prefixed by __. I admit that I don't like this
convention, but it has been adopted in the kernel. I further admit
that the C standard reserves names starting with __ for the C
implementation -- one of many things with which the kernel plays fast and
loose.
I would also recommend using <asm/bitops.h>. Why not let the kernel
coders make sure that the code is correct and efficient? I'm not sure
that it mixes with glibc and hence normal userland code. So this
might not be possible.
If you don't wish to use the kernel implementation, I strongly
recommend that you use names distinct from what the kernel uses. This
will confuse readers less.
================
Will some ALSA developer work on this? I'm willing to help, but I
hope not to have to build or test ALSA.
BTW: thanks to the team for producing such a useful product for all of
us.
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ALSA - tools 0001343]: bitops not 64bit clean
2005-11-06 22:56 ` D. Hugh Redelmeier
@ 2005-11-08 17:14 ` Takashi Iwai
0 siblings, 0 replies; 7+ messages in thread
From: Takashi Iwai @ 2005-11-08 17:14 UTC (permalink / raw)
To: D. Hugh Redelmeier; +Cc: alsa-devel
At Sun, 6 Nov 2005 17:56:30 -0500 (EST),
D. Hugh Redelmeier wrote:
>
> | From: bugtrack@alsa-project.org
> | Date: Fri, 26 Aug 2005 14:42:44 +0200
>
> | The following issue has been RESOLVED.
> | ======================================================================
> | <https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1343>
> | ======================================================================
>
> | The bitops functions (set_bit and associated) that ld10k1 use come from
> | the linux kernel, and assume that longs are 32bit only, causing a buffer
> | overflow of the bit buffer.
> |
> | The attached patch fixes the bitops to be independent of the size of
> | longs, and is confirmed to fix the bug on my box.
>
> | diff -ur alsa-tools-1.0.9/ld10k1/src/bitops.h
> | alsa-tools-1.0.9.mine/ld10k1/src/bitops.h
> | --- alsa-tools-1.0.9/ld10k1/src/bitops.h 2005-03-18 08:41:02.000000000
>
> | - addr += nr >> 5;
> | - mask = 1 << (nr & 0x1f);
> | + addr += nr >> (sizeof(long) + 1);
> | + mask = 1 << (nr & (sizeof(long) * 8 - 1));
>
> [A similar change appears two other places in the bitops.h.]
>
> You cans see this in CVS:
> http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-tools/ld10k1/src/bitops.h?rev=1.2&view=log
>
> This patch looks very wrong to me. The original code used 5 because
> it is the base 2 log of the number of bits in an unsigned long
> (thought to be always 32) and 0x1f because it is a mask with the
> length of that same 5.
>
> When sizeof(unsigned long) == 4:
> sizeof(long) + 1 == 5
> and
> log2(sizeof(unsigned long) * 8) == 5
> so the new code should work in this case.
>
> When sizeof(unsigned long) == 8
> sizeof(long) + 1 == 9
> and
> log2(sizeof(unsigned long) * 8) == 6
> so the new code should not work in this case.
Yep, right. Fixed on CVS now.
Takashi
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
^ permalink raw reply [flat|nested] 7+ messages in thread
* [ALSA - tools 0001343]: bitops not 64bit clean
@ 2005-08-16 19:13 bugtrack
0 siblings, 0 replies; 7+ messages in thread
From: bugtrack @ 2005-08-16 19:13 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1343>
======================================================================
Reported By: jdthood
Assigned To:
======================================================================
Project: ALSA - tools
Issue ID: 1343
Category: ld10k1
Reproducibility: always
Severity: major
Priority: normal
Status: new
======================================================================
Date Submitted: 08-16-2005 20:49 CEST
Last Modified: 08-16-2005 21:13 CEST
======================================================================
Summary: bitops not 64bit clean
Description:
Quoting Debian bug report #323331:
Package: ld10k1
Version: 1.0.9-1
On all 64bit systems (the easiest example is amd64) ld10k1 crashes on
use by lo10k1, some debugging tracked down the problem fairly quickly.
The bitops functions (set_bit and associated) that ld10k1 use come from
the linux kernel, and assume that longs are 32bit only, causing a buffer
overflow of the bit buffer.
The attached patch fixes the bitops to be independent of the size of
longs, and is confirmed to fix the bug on my box.
Zephaniah E. Hull.
diff -ur alsa-tools-1.0.9/ld10k1/src/bitops.h
alsa-tools-1.0.9.mine/ld10k1/src/bitops.h
--- alsa-tools-1.0.9/ld10k1/src/bitops.h 2005-03-18 08:41:02.000000000
-0500
+++ alsa-tools-1.0.9.mine/ld10k1/src/bitops.h 2005-08-15
23:24:46.000000000 -0400
@@ -15,13 +15,17 @@
*
* C language equivalents written by Theodore Ts'o, 9/26/92
*/
+/*
+ * Converted to be independent of the size of longs.
+ * Zephaniah E. Hull 2005-08-15.
+ */
__inline__ int set_bit(int nr, unsigned long * addr)
{
int mask, retval;
- addr += nr >> 5;
- mask = 1 << (nr & 0x1f);
+ addr += nr >> (sizeof(long) + 1);
+ mask = 1 << (nr & (sizeof(long) * 8 - 1));
retval = (mask & *addr) != 0;
*addr |= mask;
return retval;
@@ -31,8 +35,8 @@
{
int mask, retval;
- addr += nr >> 5;
- mask = 1 << (nr & 0x1f);
+ addr += nr >> (sizeof(long) + 1);
+ mask = 1 << (nr & (sizeof(long) * 8 - 1));
retval = (mask & *addr) != 0;
*addr &= ~mask;
return retval;
@@ -42,8 +46,8 @@
{
int mask;
- addr += nr >> 5;
- mask = 1 << (nr & 0x1f);
+ addr += nr >> (sizeof(long) + 1);
+ mask = 1 << (nr & (sizeof(long) * 8 - 1));
return ((mask & *addr) != 0);
}
======================================================================
----------------------------------------------------------------------
rlrevell - 08-16-05 20:52
----------------------------------------------------------------------
Um, what are those being used for? I don't think the emu10k1 has any 64
bit registers so why on earth would you need to set a bit in a 64 bit
variable? Are you sure they are not supposed to be u32?
----------------------------------------------------------------------
pzad - 08-16-05 21:13
----------------------------------------------------------------------
This is used to set used (valid) GPRs, TRAM, code maps in CODE_POKE ioctl.
Issue History
Date Modified Username Field Change
======================================================================
08-16-05 20:49 jdthood New Issue
08-16-05 20:52 rlrevell Note Added: 0005832
08-16-05 21:13 pzad Note Added: 0005833
======================================================================
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 7+ messages in thread* [ALSA - tools 0001343]: bitops not 64bit clean
@ 2005-08-16 18:52 bugtrack
0 siblings, 0 replies; 7+ messages in thread
From: bugtrack @ 2005-08-16 18:52 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1343>
======================================================================
Reported By: jdthood
Assigned To:
======================================================================
Project: ALSA - tools
Issue ID: 1343
Category: ld10k1
Reproducibility: always
Severity: major
Priority: normal
Status: new
======================================================================
Date Submitted: 08-16-2005 20:49 CEST
Last Modified: 08-16-2005 20:52 CEST
======================================================================
Summary: bitops not 64bit clean
Description:
Quoting Debian bug report #323331:
Package: ld10k1
Version: 1.0.9-1
On all 64bit systems (the easiest example is amd64) ld10k1 crashes on
use by lo10k1, some debugging tracked down the problem fairly quickly.
The bitops functions (set_bit and associated) that ld10k1 use come from
the linux kernel, and assume that longs are 32bit only, causing a buffer
overflow of the bit buffer.
The attached patch fixes the bitops to be independent of the size of
longs, and is confirmed to fix the bug on my box.
Zephaniah E. Hull.
diff -ur alsa-tools-1.0.9/ld10k1/src/bitops.h
alsa-tools-1.0.9.mine/ld10k1/src/bitops.h
--- alsa-tools-1.0.9/ld10k1/src/bitops.h 2005-03-18 08:41:02.000000000
-0500
+++ alsa-tools-1.0.9.mine/ld10k1/src/bitops.h 2005-08-15
23:24:46.000000000 -0400
@@ -15,13 +15,17 @@
*
* C language equivalents written by Theodore Ts'o, 9/26/92
*/
+/*
+ * Converted to be independent of the size of longs.
+ * Zephaniah E. Hull 2005-08-15.
+ */
__inline__ int set_bit(int nr, unsigned long * addr)
{
int mask, retval;
- addr += nr >> 5;
- mask = 1 << (nr & 0x1f);
+ addr += nr >> (sizeof(long) + 1);
+ mask = 1 << (nr & (sizeof(long) * 8 - 1));
retval = (mask & *addr) != 0;
*addr |= mask;
return retval;
@@ -31,8 +35,8 @@
{
int mask, retval;
- addr += nr >> 5;
- mask = 1 << (nr & 0x1f);
+ addr += nr >> (sizeof(long) + 1);
+ mask = 1 << (nr & (sizeof(long) * 8 - 1));
retval = (mask & *addr) != 0;
*addr &= ~mask;
return retval;
@@ -42,8 +46,8 @@
{
int mask;
- addr += nr >> 5;
- mask = 1 << (nr & 0x1f);
+ addr += nr >> (sizeof(long) + 1);
+ mask = 1 << (nr & (sizeof(long) * 8 - 1));
return ((mask & *addr) != 0);
}
======================================================================
----------------------------------------------------------------------
rlrevell - 08-16-05 20:52
----------------------------------------------------------------------
Um, what are those being used for? I don't think the emu10k1 has any 64
bit registers so why on earth would you need to set a bit in a 64 bit
variable? Are you sure they are not supposed to be u32?
Issue History
Date Modified Username Field Change
======================================================================
08-16-05 20:49 jdthood New Issue
08-16-05 20:52 rlrevell Note Added: 0005832
======================================================================
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 7+ messages in thread* [ALSA - tools 0001343]: bitops not 64bit clean
@ 2005-08-16 18:49 bugtrack
0 siblings, 0 replies; 7+ messages in thread
From: bugtrack @ 2005-08-16 18:49 UTC (permalink / raw)
To: alsa-devel
The following issue has been SUBMITTED.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1343>
======================================================================
Reported By: jdthood
Assigned To:
======================================================================
Project: ALSA - tools
Issue ID: 1343
Category: ld10k1
Reproducibility: always
Severity: major
Priority: normal
Status: new
======================================================================
Date Submitted: 08-16-2005 20:49 CEST
Last Modified: 08-16-2005 20:49 CEST
======================================================================
Summary: bitops not 64bit clean
Description:
Quoting Debian bug report #323331:
Package: ld10k1
Version: 1.0.9-1
On all 64bit systems (the easiest example is amd64) ld10k1 crashes on
use by lo10k1, some debugging tracked down the problem fairly quickly.
The bitops functions (set_bit and associated) that ld10k1 use come from
the linux kernel, and assume that longs are 32bit only, causing a buffer
overflow of the bit buffer.
The attached patch fixes the bitops to be independent of the size of
longs, and is confirmed to fix the bug on my box.
Zephaniah E. Hull.
diff -ur alsa-tools-1.0.9/ld10k1/src/bitops.h
alsa-tools-1.0.9.mine/ld10k1/src/bitops.h
--- alsa-tools-1.0.9/ld10k1/src/bitops.h 2005-03-18 08:41:02.000000000
-0500
+++ alsa-tools-1.0.9.mine/ld10k1/src/bitops.h 2005-08-15
23:24:46.000000000 -0400
@@ -15,13 +15,17 @@
*
* C language equivalents written by Theodore Ts'o, 9/26/92
*/
+/*
+ * Converted to be independent of the size of longs.
+ * Zephaniah E. Hull 2005-08-15.
+ */
__inline__ int set_bit(int nr, unsigned long * addr)
{
int mask, retval;
- addr += nr >> 5;
- mask = 1 << (nr & 0x1f);
+ addr += nr >> (sizeof(long) + 1);
+ mask = 1 << (nr & (sizeof(long) * 8 - 1));
retval = (mask & *addr) != 0;
*addr |= mask;
return retval;
@@ -31,8 +35,8 @@
{
int mask, retval;
- addr += nr >> 5;
- mask = 1 << (nr & 0x1f);
+ addr += nr >> (sizeof(long) + 1);
+ mask = 1 << (nr & (sizeof(long) * 8 - 1));
retval = (mask & *addr) != 0;
*addr &= ~mask;
return retval;
@@ -42,8 +46,8 @@
{
int mask;
- addr += nr >> 5;
- mask = 1 << (nr & 0x1f);
+ addr += nr >> (sizeof(long) + 1);
+ mask = 1 << (nr & (sizeof(long) * 8 - 1));
return ((mask & *addr) != 0);
}
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
08-16-05 20:49 jdthood New Issue
======================================================================
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2005-11-08 17:14 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-08-17 10:23 [ALSA - tools 0001343]: bitops not 64bit clean bugtrack
-- strict thread matches above, loose matches on Subject: below --
2005-08-26 12:42 bugtrack
2005-11-06 22:56 ` D. Hugh Redelmeier
2005-11-08 17:14 ` Takashi Iwai
2005-08-16 19:13 bugtrack
2005-08-16 18:52 bugtrack
2005-08-16 18:49 bugtrack
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox