[Python-Dev] test_itertools fails for trunk on x86 OS X machine

[Jack Diederich]

On Fri, Sep 22, 2006 at 06:09:41AM +0200, "Martin v. L?wis" wrote:
> Jack Diederich schrieb:
> > Faced with the choice of believing in a really strange platform specific 
> > bug in a commonly used routine that resulted in exactly the failure caused 
> > by one of the two files being updated or believing a failure occurred in the
> > long chain of networks, disks, file systems, build tools, and operating 
> > systems that would result in only one of the files being updated -
> > I went with the latter.
> 
> Please reconsider how subversion works. It has the notion of atomic
> commits, so you either get the entire change, or none at all.
> 
> Fortunately, the buildbot keeps logs of everything it does:
> 
> http://www.python.org/dev/buildbot/trunk/g4%20osx.4%20trunk/builds/1449/step-svn/0
> 
> shows
> 
> U    Lib/test/test_itertools.py
> U    Modules/itertoolsmodule.c
> Updated to revision 51950.
> 
> So it said it updated both files. But perhaps it didn't build them?
> Let's check:
> 
> 
> http://www.python.org/dev/buildbot/trunk/g4%20osx.4%20trunk/builds/1449/step-compile/0
> 
> has this:
> 
> building 'itertools' extension
> 
> gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp
> -mno-fused-madd -g -Wall -Wstrict-prototypes -I.
> -I/Users/buildslave/bb/trunk.psf-g4/build/./Include
> -I/Users/buildslave/bb/trunk.psf-g4/build/./Mac/Include -I./Include -I.
> -I/usr/local/include -I/Users/buildslave/bb/trunk.psf-g4/build/Include
> -I/Users/buildslave/bb/trunk.psf-g4/build -c
> /Users/buildslave/bb/trunk.psf-g4/build/Modules/itertoolsmodule.c -o
> build/temp.macosx-10.3-ppc-2.6/Users/buildslave/bb/trunk.psf-g4/build/Modules/itertoolsmodule.o
> 
> gcc -bundle -undefined dynamic_lookup
> build/temp.macosx-10.3-ppc-2.6/Users/buildslave/bb/trunk.psf-g4/build/Modules/itertoolsmodule.o
> -L/usr/local/lib -o build/lib.macosx-10.3-ppc-2.6/itertools.so
> 
> So itertools.so is regenerated, as it should; qed.
> 

I should leave the tounge-in-cheek bombast to Tim and Frederik, especially
when dealing with what might be an OS & machine specific bug.  The next
checkin and re-test will or won't highlight a failure and certainly someone 
with a g4 will try it out before 2.5.1 goes out so we'll know if it was a 
fluke soonish. The original error was mine, I typed "Size_t" instead of 
"Ssize_t" and while my one-char patch might also be wrong (I hope not, I'm 
red-faced enough as is) we should find out soon enough.

-Jack