[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Serious bug in GUILE rational handling.
From: |
Han-Wen Nienhuys |
Subject: |
Serious bug in GUILE rational handling. |
Date: |
Sat, 23 Dec 2006 21:22:39 +0100 |
User-agent: |
Thunderbird 1.5.0.8 (X11/20061107) |
Hello,
scm_equal_p inspects SCM_CELL_TYPE() of a rational. Cell type is also used
to hold the reduced bit. This leads to interesting behavior,
guile> (define x 1/2)
guile> (define y 1/2)
guile> (denominator x)
2
guile> (equal? x y)
#f
guile>
This took a lot of effort to debug; printing the rational while
debugging would alter the reduction bit, making the problem go away,
suggesting memory corruption rather than a programming error.
Furthermore, I think
if (!(SCM_FRACTION_REDUCED (z)))
{
SCM divisor;
divisor = scm_gcd (SCM_FRACTION_NUMERATOR (z), SCM_FRACTION_DENOMINATOR
(z));
if (!(scm_is_eq (divisor, SCM_I_MAKINUM(1))))
{
/* is this safe? */
SCM_FRACTION_SET_NUMERATOR (z, scm_divide (SCM_FRACTION_NUMERATOR
(z), divisor));
SCM_FRACTION_SET_DENOMINATOR (z, scm_divide (SCM_FRACTION_DENOMINATOR
(z), divisor));
}
SCM_FRACTION_REDUCED_SET (z);
}
introduces a race condition.
Suppose another thread triggers scm_i_fraction_reduce at the same
time, and reads the partial result of the first scm_i_fraction_reduce.
This is really insidious, as the corruption would happen upon reading
the data, and will show up somewhere completely different.
I have removed support for the reduced bit, and put the reduction in
make_fraction.
I am about to commit these changes to CVS, and will also commit them
to the GUILE 1.8 branch. I would appreciate it if a GUILE 1.8.2 would
be released ASAP. I need working rational numbers in GUILE for
LilyPond 2.11.x, and it would be nice if I didn't have to force my
users to run GUILE from CVS.
--
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen
- Serious bug in GUILE rational handling.,
Han-Wen Nienhuys <=