This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients python-dev, serhiy.storchaka, vstinner, xiang.zhang
Date 2017-01-09.17:10:22
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1483981823.01.0.318409235293.issue28870@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2017-01-09 17:10:23vstinnersetrecipients: + vstinner, python-dev, serhiy.storchaka, xiang.zhang
2017-01-09 17:10:23vstinnersetmessageid: <1483981823.01.0.318409235293.issue28870@psf.upfronthosting.co.za>
2017-01-09 17:10:22vstinnerlinkissue28870 messages
2017-01-09 17:10:22vstinnercreate