[Matt Hamilton]
Yes, I've tried increasing the stack size. I think it is a platform specific problem for threads on FreeBSD/AMD64. Regardless of how large I make the stack, or how low I set the recursionlimit, python 2.3.4 cannot complete test_re.py sucessfully on this platform.
FYI, the sys module's recursion limit only kicks in when Python functions are calling Python functions. The re engine is coded entirely in C, and recursions at the C level "don't count" toward the sys module's recursion limit. IOW, only the stack size is relevant for test_re in 2.3.4.
I've tried bringing it up on the FreeBSD lists, but not got much of a response. Python 2.4a3 must do *something* different with threads, as it can complete test_re.py on the same platform.
test_re is probably a red herring here: starting with 2.4a1, Python's re C implementation became *far* less recursive than prior implementations. IOW, running test_re under 2.4 is a very different (and much easier on the stack) thing than running test_re under 2.3. So looking at test_re alone doesn't really imply anything about threads. The biggest stack hog in 2.4's test suite is the new test_compiler, but it takes so long it only runs a subset by default. Pass "-u all test_compiler" to regrtest.py to run the whole thing. If that passes (== no output other than "1 test OK.")-- and it should --that's a severe test of both the C stack and sys's recursion limit.
I've tried backporting over thread_pthread.py from 2.4a3, but that doesn't do it. I think there may be extra defines set in the Makefile or configure.
Possibly, but I'm not optimistic about that line. That test_re failed in 2.3.4 said you have "stack problems". That test_re passed in 2.4 just says that 2.4's re implementation doesn't stress the stack anymore. But (the full) test_compiler does, so I'm betting that blows up under 2.4 for you.