On Monday 16 June 2003 20:16, George Woltman wrote:
>
> I'm also adding code to 23.5 to check EVERY iteration for an impossible
> result such as -2, -1, 0, 1, 2.  This test will be very, very quick.

Sounds sensible to me ... but, does it not make sense to run this test during 
those iterations when testing for excess roundoff error occurs, i.e. normally 
only 1 in 128 iterations? The point here is that, once the residual gets into 
a loop like this, it won't get out again.
>
> FYI, six times a result of 0000000000000002 has been reported to the
> server.  So, somehow or another it is possible for a hardware error to
> zero the FFT data without triggering an ILLEGAL SUMOUT.
>
Any instances of FFFFFFFFFFFFFFFE? Should be about as common, if this is a 
hardware related problem.

There are lots of reasons why memory corruption may occur but, in most cases, 
it is hard to see how a whole block of data should be filled with zero (or 
one) bits without corrupting the program code in such a way that the program 
would crash or have the operating system crash from under it. I think the 
most likely scenario would be that a pointer to the FFT work space could be 
corrupted & point to virtual memory which has "zero on demand" attribute. 
This might be detectable by memory leak even on systems without proper memory 
protection (Win 9x) but could be fixed easily enough by keeping _two_ 
pointers to critical work space (the values don't change that often...) & 
comparing them occasionally. As to why the pointer might get corrupted, most 
likely we're looking at stack overflow or some other program behaving badly 
rather than a bug internal to Prime95.

It would be interesting (though probably impossible) to check which OS the 
"residue 2" runs were run on. If my logic is right then I would suspect that 
they were all run on Win 9x/ME rather than NT, W2K, XP or any of the 
varieties of linux, where proper memory protection should give much better 
protection against this sort of problem.

Regards
Brian Beesley
_________________________________________________________________________
Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm
Mersenne Prime FAQ      -- http://www.tasam.com/~lrwiman/FAQ-mers

Reply via email to