[moving to python-dev]
[Tim, gets different results across whole runs of
python_d ../Lib/test/regrtest.py -R 2:40: test_filecmp test_exceptions
]
>>> Does that make any sense? Not to me -- I don't know of a clear reason
>>> other than wild loads/stores for why such runs should ever differ.
[Neal]
>> The problem generally has to do with modules cacheing things.
[Martin]
> Then the numbers should repeat on each run.
Right. The point wasn't that I saw a variety of different integers in
the "leak vector" in a single run, it was that I got different results
_across_ runs: no leaks in either test, a leak in one but not the
other, or (very rarely) leaks in both.
> So wild loads/stores are a more compelling explanation. Of course, it
> *should* even be repeatable with wild loads/stores, unless the OS
> shuffles the address space on each run (which at least Linux,
> unfortunately, does).
Well, I just tried this (illegal) C program under VC 7.1:
#include <stdio.h>
#include <stdlib.h>
int main() {
int *p;
int i, sum;
p = (int *)malloc(sizeof(int));
printf("%p %d ...", p, sum);
for (sum = 0, i = -12; i < 29; ++i)
sum += p[i];
printf("%d\n", sum);
return 0;
}
Here are several runs. Note that the address malloc() returns is
always the same, but adding the junk "around" that address often gives
a different result, and the stack trash `sum` contains at first also
varies. Put those together, and they show that wild loads from stack
trash _and_ heap trash can vary across runs:
C:\Code>cl boogle.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
boogle.c
c:\code\boogle.c(9) : warning C4700: local variable 'sum' used without
having been initialized
Microsoft (R) Incremental Linker Version 7.10.3077
Copyright (C) Microsoft Corporation. All rights reserved.
/out:boogle.exe
boogle.obj
C:\Code>for %i in (1 2 3 4 5 6 7 8 9) do boogle.exe
C:\Code>boogle.exe
00322EA8 315894624 ...75845519
C:\Code>boogle.exe
00322EA8 316050874 ...125913836
C:\Code>boogle.exe
00322EA8 316050874 ...125913836
C:\Code>boogle.exe
00322EA8 316207124 ...8930763
C:\Code>boogle.exe
00322EA8 316207124 ...8930763
C:\Code>boogle.exe
00322EA8 316207124 ...8930763
C:\Code>boogle.exe
00322EA8 316363374 ...42224689
C:\Code>boogle.exe
00322EA8 316363374 ...42224689
C:\Code>boogle.exe
00322EA8 316519624 ...92948238
How did I pick -12 and 29 for i's bounds? Easy: I started with much
larger bounds, and reduced them haphazardly until the program stopped
segfaulting :-)
Now I hate to think this is "the cause" for regrtest -R varying across
identical runs, but I don't have many other suspects in mind. For
example, I tried forcing random.seed() at the start of
regrtest.main(), but that didn't make any visible difference.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
