Thomas> In one test I did, it crashed in int_print, the print function Thomas> for int objects, which did 'fprintf(fp, "%ld", v->ival);'. The Thomas> actual SEGV arrived inside fprintf's internals. v->ival was a Thomas> valid integer (though a high one) and the problem was not Thomas> derefrencing 'v'. 'fp' was stderr, according to its _fileno Thomas> member. I get something similar. The script conks out after 4491 calls (this with a threaded interpreter). It segfaults in _IO_vfprintf trying to print 4492 to stdout. All arguments to _IO_vfprintf appear valid (though I'm not quite sure how to print the third, va_list, argument). When I configure --without-threads, the script runs much longer, making it past 18068. It conks out in the same spot, however, trying to print 18069. The fact that it occurs in the same place with and without threads (the addresses of the two different _IO_vfprintf functions are different, which implies different stdio libraries are active in the threading and non-threading versions as Thomas said), suggests to me that the problem may simply be that in the threading case each thread (even the main thread) is limited to a much smaller stack. Perhaps I'm seeing what I'm supposed to see. If the two versions were to crap out for different reasons, I doubt I'd see them failing in the same place. Skip