From: Kevin Ryde <user42@zip.com.au>
Cc: schottstaedt@ccrma.stanford.edu, guile-devel@gnu.org,
Jan Nieuwenhuizen <janneke@gnu.org>
Subject: Re: Serious bug in GUILE rational handling.
Date: Sun, 24 Dec 2006 10:21:45 +1100 [thread overview]
Message-ID: <87slf66vw6.fsf@zip.com.au> (raw)
In-Reply-To: <458D900F.1020108@xs4all.nl> (Han-Wen Nienhuys's message of "Sat, 23 Dec 2006 21:22:39 +0100")
Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
>
> 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.
Nasty.
> 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.
Yep. I think I might have raised that when fractions were introduced,
then promptly never did anything about it. My best idea at the time
was if fractions are stored unreduced then gc would be a good
thread-safe place to look for reductions to save space.
I don't know if reduced or unreduced is a better representation. My
guess would be that gcds are so horrendously expensive that unreduced
is often what you want, if it's do-able. Reducing lazily sounds like
the best of both worlds, but as you point out would need multithread
protection.
> I am about to commit these changes to CVS, and will also commit them
> to the GUILE 1.8 branch.
Do you have a test case for numbers.test? Not that I doubt the fix,
just to illustrate what now works.
I took the liberty of adding a NEWS entry too.
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
next prev parent reply other threads:[~2006-12-23 23:21 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-23 20:22 Serious bug in GUILE rational handling Han-Wen Nienhuys
2006-12-23 20:55 ` Han-Wen Nienhuys
2006-12-23 23:02 ` Kevin Ryde
2006-12-23 23:21 ` Kevin Ryde [this message]
2006-12-24 0:59 ` Han-Wen Nienhuys
2006-12-25 21:33 ` Kevin Ryde
2006-12-24 1:06 ` Han-Wen Nienhuys
2006-12-24 9:43 ` Kevin Ryde
2007-01-03 21:35 ` Carl Witty
2006-12-23 23:41 ` Kevin Ryde
-- strict thread matches above, loose matches on Subject: below --
2006-12-24 11:32 Serious bug inn " Bill Schottstaedt
2006-12-29 2:52 ` Neil Jerram
2006-12-29 12:39 ` Serious bug in " Bill Schottstaedt
2006-12-30 20:42 ` Neil Jerram
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87slf66vw6.fsf@zip.com.au \
--to=user42@zip.com.au \
--cc=guile-devel@gnu.org \
--cc=janneke@gnu.org \
--cc=schottstaedt@ccrma.stanford.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).