[Neal Norwitz] > ... > I also think I know how to do the "double builds" (one release and one > debug). But it's too late for me to change it tonight without > screwing it up.
I'm not mad :-). The debug build is more fruitful than the release build for finding problems, so doing two debug-build runs is an improvement (keeping in mind that some bugs only show up in release builds, though -- for example, subtly incorrect C code that works differently depending on whether compiler optimization is in effect). > The good/bad news after this change is: > > http://www.python.org/dev/buildbot/all/g4%20osx.4%20trunk/builds/145/step-test/0 > > A seg fault on Mac OS when running with -r. :-( Yay! That's certainly good/bad news. Since I always run with -r, I've had the fun of tracking most of these down. Sometimes it's very hard, sometimes not. regrtest's -f option is usually needed, to force running the tests in exactly the same order, then commenting test names out in binary-search fashion to get a minimal subset. Alas, half the time the cause for a -r segfault turns out to be an error in refcounting or in setting up gc'able containers, and has nothing in particular to do with the specific tests being run. Those are the "very hard" ones ;-) Setting the gc threshold to 1 (do a full collection on every allocation) can sometimes provoke such problems easily. _______________________________________________ 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
