Message285055
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. |
|
Date |
User |
Action |
Args |
2017-01-09 17:10:23 | vstinner | set | recipients:
+ vstinner, python-dev, serhiy.storchaka, xiang.zhang |
2017-01-09 17:10:23 | vstinner | set | messageid: <1483981823.01.0.318409235293.issue28870@psf.upfronthosting.co.za> |
2017-01-09 17:10:22 | vstinner | link | issue28870 messages |
2017-01-09 17:10:22 | vstinner | create | |
|