[Python-checkins] Python Regression Test Failures refleak (1)

Tim Peters tim.peters at gmail.com
Mon Jun 5 19:30:52 CEST 2006


[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.


More information about the Python-checkins mailing list