Skip Montanaro writes: > 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. Yes, libpthread defines it's own version of _IO_vprintf. Try this experiment: do a "ulimit -a" to see what the stack size limit is; start your Python process; find it's PID, and before you start your test, go into another window and run the command watch -n 0 "grep Stk /proc/<pythonpid>/status" This will show exactly how much stack Python is using. Then start the runaway-recursion test. If it craps out when the stack usage hits the rlimit, you are seeing what you are supposed to see. If it craps out anytime sooner, there is a real bug of some sort, as I'm 99% sure there is.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4