STINNER Victor added the comment: I modified Serhiy's stack_overflow.py of #28858: * re-run each test 10 tests and show the maximum depth * only test: ['test_python_call', 'test_python_getitem', 'test_python_iterator']
Maximum number of Python calls before a crash. (*) Reference (unpatched): 560 bytes/call test_python_call 7172 test_python_getitem 6232 test_python_iterator 5344 => total: 18 838 (1) no_small_stack.patch: 368 bytes/call test_python_call 7172 (=) test_python_getitem 6544 (+312) test_python_iterator 5572 (+228) => total: 19 288 (2) less_stack.patch: 384 bytes/call test_python_call 7272 (+100) test_python_getitem 6384 (+152) test_python_iterator 5456 (+112) => total: 19 112 (3) subfunc.patch: 496 bytes test_python_call 7272 (+100) test_python_getitem 6712 (+480) test_python_iterator 6020 (+678) => total: 20 004 (4) alloca.patch: 528 bytes/call test_python_call 7272 (+100) test_python_getitem 6464 (+232) test_python_iterator 5752 (+408) => total: 19 488 Patched sorted by bytes/call, from best to worst: no_small_stack.patch (368) > less_stack.patch (384) > subfunc.patch (496) > alloca.patch (528) > reference (560). Patched sorted by number of calls before crash: subfunc.patch (20 004) > alloca.patch (19 488) > no_small_stack.patch (19 288) > less_stack.patch (19 112) > reference (18 838). I expected a correlation between the measure bytes/call measured by testcapi_stacksize.patch and the number of calls before a crash, but I fail to see an obvious correlation :-/ Maybe the compiler is smarter than what I would expect and emits efficient code to be able to use less stack memory? Maybe the Linux kernel does weird things which makes the behaviour on stack-overflow non-obvious :-) At least, I would expect that no_small_stack.patch would be the clear winner, since it has the smallest usage of C stack. ---------- Added file: http://bugs.python.org/file46230/stack_overflow_28870.py _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28870> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com