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

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-Dev mailing list