1. Is there a test or code snippet that I can run to confirm that this is what
ails my system?
A trivial C program can be used to demonstrate:
---8<--- stest.c ---8<---
#include <stdio.h>
int recursion_func(int t1, int t2, int t3);
int main(void)
{
printf("counter = %d\n", recursion_func(25, 15, 1));
return 0;
}
---8<------8<-------8<---
---8<--- rfunc.c ---8<---
int recursion_func(int t1, int t2, int t3)
{
int z1, z2, z3;
double x1, x2, x3;
z1 = t1 << 2;
z2 = t2 << 2;
z3 = t3 << 2;
x1 = 3.47 * z1;
x2 = 1.29 * z2;
x3 = -2.47 * z3;
return x1 * x2 - x3 > 1.5e30 ? t3 : recursion_func(++t1, ++t2, ++t3);
}
---8<------8<-------8<---
Note that the recursion function was made more complex than might have
been needed to try to force larger stack frames. I was also trying to
avoid gcc's optimiser undoing the recursion at higher levels of
optimisation - this worked with gcc 2.95, but gcc 3.3.2 seems to be able
to make this test non-recursive even with -Os ... :-|
On FreeBSD, this is built by
$ gcc -g -O -pthread -c rfunc.c
$ gcc -g -O -pthread -c stest.c
$ gcc -g -O -pthread -o stest stest.o rfunc.o
You'll have to adapt for Linux. Running this:
$ ./stest
Bus error (core dumped)
$ gdb stest stest.core
GNU gdb 4.18 (FreeBSD)
{...copyright stuff elided...}
Program terminated with signal 10, Bus error.
Reading symbols from /usr/lib/libc_r.so.4...done.
Reading symbols from /usr/libexec/ld-elf.so.1...done.
#0 0x80484ce in recursion_func (t1=21846, t2=21836, t3=21822)
at pthread_recursion_test_aux.c:3
3 int recursion_func(int t1, int t2, int t3)
(gdb)
libc_r is the pthread-supporting libc.
Building without the "-pthread" switch uses the non-threaded libc, which
results in:
$ ./stest
Segmentation fault (core dumped)
$ gdb stest stest.core
{...}
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libc.so.4...done.
Reading symbols from /usr/libexec/ld-elf.so.1...done.
#0 0x8048530 in recursion_func (t1=1398102, t2=1398092, t3=1398078)
at pthread_recursion_test_aux.c:16
16 return x1 * x2 - x3 > 1.5e30 ? t3 : recursion_func(++t1,
++t2, +
+t3);
(gdb)
In this case, I know the stack size is 64MB; the ratio t1 values between
the two matches 1MB to 64MB.
2. If this *is* the problem, what would be a good workaround?
If you can do without threads, build the Python interpreter that way.
I suggest that you enquire of glibc forums whether there is any way to
tweak the primary thread stack size by some runtime means, otherwise
the only option would probably require changing a library header file and
recompiling glibc :-( (which is what's required on FreeBSD 4.x - don't
know about 5.x).
