|
From: Tom H. <to...@co...> - 2006-09-21 15:40:40
|
In message <30c...@lo...>
Tom Hughes <to...@co...> wrote:
> In message <200...@ac...>
> Julian Seward <js...@ac...> wrote:
>
>> Hmm. 2.6.16 isn't exactly what you'd call an ancient and buggy kernel.
>
> I've seen it on a range of recent 2.6 kernels.
I've just reproduced it on a 2.6.17-1.2157_FC5 kernel.
>> But .. [thinks] isn't this a red herring? If 3.2.0 does
>> not fail on your box when running your Fortran app but 3.2.1 does,
>> then it has to be a regression in 3.2.1. That's what you're
>> saying happened, right?
>
> We were definitely seeing it in 3.2.0 although it is relatively
> rare - the longer valgrind is running the more likely it is to
> trigger. We first saw it doing long callgrind runs, but I have
> seen it from memcheck as well.
I can reproduce it outside valgrind - here is my test program:
#include <assert.h>
#include <sched.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char **argv)
{
uint16_t cw = 0x27f;
asm("fldcw %0" : : "m" (cw));
while ( 1 )
{
asm("fstcw %0" : : "m" (cw));
printf("cw = %x\n", cw);
if (cw != 0x27f)
{
fprintf(stderr, "cw = 0x%x\n", cw);
abort();
}
sched_yield();
}
exit( 0 );
}
I ran that and after a few hours (during which I tried to load the
machine up as much as possible) it failed with the control word having
changed from 0x27f to 0x37f.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|