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 josh.r
Recipients josh.r, rhettinger, serhiy.storchaka, sir-sigurd, vstinner
Date 2019-02-26.16:42:10
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1551199330.94.0.661866716114.issue36030@roundup.psfhosted.org>
In-reply-to
Content
Victor/vstinner: Isn't PR 12032 reintroducing the issue fixed in #29234? _PyStack_AsTuple was explicitly marked as _Py_NO_INLINE because inlining was creating excessive stack consumption in the callers (which were the bytecode interpreter loop), but the new _PyTuple_FromArray isn't marked as _Py_NO_INLINE, so the swap reintroduces the problem.

Seems like either:

1. _PyTuple_FromArray should also be marked _Py_NO_INLINE

or

2. _PyStack_AsTuple should continue to exist as the non-inlined version of _PyTuple_FromArray

It's possible this isn't as much of an issue because _PyTuple_FromArray is in tupleobject.c (where it's only called in one place), while _PyStack_AsTuple was in call.c and was called from within call.c in four places, but only if link-time optimization isn't involved (and in practice, most public distributions of CPython are built with link-time optimization now, correct?); if LTO is enabled, the same stack bloat issues are possible.
History
Date User Action Args
2019-02-26 16:42:10josh.rsetrecipients: + josh.r, rhettinger, vstinner, serhiy.storchaka, sir-sigurd
2019-02-26 16:42:10josh.rsetmessageid: <1551199330.94.0.661866716114.issue36030@roundup.psfhosted.org>
2019-02-26 16:42:10josh.rlinkissue36030 messages
2019-02-26 16:42:10josh.rcreate