classification
Title: Rework CALL_FUNCTION* opcodes
Type: enhancement Stage: resolved
Components: Interpreter Core Versions: Python 3.6
process
Status: closed Resolution: fixed
Dependencies: 27140 Superseder:
Assigned To: serhiy.storchaka Nosy List: Demur Rumed, Mark.Shannon, berker.peksag, haypo, python-dev, rbcollins, serhiy.storchaka, yselivanov
Priority: normal Keywords: patch

Created on 2016-06-04 07:45 by serhiy.storchaka, last changed 2016-09-22 21:13 by haypo. This issue is now closed.

Files
File name Uploaded Description Edit
callfunc.patch Demur Rumed, 2016-06-19 17:38 review
callfunc2.patch Demur Rumed, 2016-06-20 23:45 review
callfunc3.patch Demur Rumed, 2016-07-01 14:10 review
callfunc4.patch Demur Rumed, 2016-07-09 20:02 review
callfunc5.patch Demur Rumed, 2016-07-15 23:22 review
callfunc-6.patch haypo, 2016-09-06 22:16 review
callfunc-7.patch haypo, 2016-09-09 05:07 review
callfunc-8.patch haypo, 2016-09-09 05:47 review
callfunc-9.patch serhiy.storchaka, 2016-09-09 19:48 review
callfunc-10.patch serhiy.storchaka, 2016-09-09 21:23 review
callfunc-11.patch serhiy.storchaka, 2016-09-11 06:29 review
callfunc-12.patch serhiy.storchaka, 2016-09-11 10:07 review
Repositories containing patches
vlad
Messages (55)
msg267241 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2016-06-04 07:45
Currently there are 4 opcodes (CALL_FUNCTION, CALL_FUNCTION_VAR, CALL_FUNCTION_KW, CALL_FUNCTION_VAR_KW) for calling a function depending of presenting the var-positional and var-keyword arguments:

    func(arg1, ..., argN, name1=kwarg1, ..., nameM=kwargM)
    func(arg1, ..., argN, *args, name1=kwarg1, ..., nameM=kwargM)
    func(arg1, ..., argN, name1=kwarg1, ..., nameM=kwargM, **kwargs)
    func(arg1, ..., argN, *args, name1=kwarg1, ..., nameM=kwargM, **kwargs)

The number of positional and keyword arguments are packed in oparg, and both numbers are limited by 255. Thus the single keyword argument makes oparg not fitting in 8 bit and requires EXTENDED_ARG. The stack contains first positional arguments, then optional args tuple, then keyword arguments, then optional kwargs dict. For every keyword argument the two values are pushed on the stack: argument name (always constant string) and argument value.

I collected a statistic about opcodes in compiled code during running Python tests [1] (maybe it is biased, but this is large and multifarious assembly, and I hope it takes some representation about average Python code). According to it about 90% of compiled function calls are calls with the fixed number of positional arguments (CALL_FUNCTION with oparg < 256), the rest 10% are calls with the fixed number of positional and keyword arguments (CALL_FUNCTION with oparg >= 256), and only about 0.5% are calls with the var-positional or var-keyword arguments.

I propose to use the different sets of opcodes that corresponds to these cases:

    func(arg1, ..., argN)
    func(arg1, ..., argN, name1=kwarg1, ..., nameM=kwargM)
    func(*args, **kwargs)

1. CALL_FUNCTION takes the fixed number of positional arguments. oparg is the number of arguments. The stack contains positional arguments.

2. CALL_FUNCTION_KW takes the fixed number of positional and keyword arguments. oparg is the number of all arguments. The stack contains values of arguments (first positional, then keyword), then a tuple of keyword names (as in proposed new opcode BUILD_CONST_KEY_MAP in issue27140).

3. CALL_FUNCTION_EX takes the variable number of positional and keyword arguments. oparg is 0. The stack contains a tuple of positional arguments and a dict of keyword arguments (they are build in the bytecode with using BUILD_TUPLE, BUILD_CONST_KEY_MAP, BUILD_LIST_UNPACK and BUILD_MAP_UNPACK_WITH_CALL). This is the most general variant, others exist just for the optimization of common cases.

Benefits:

1. Calling a function with keyword arguments uses less stack and less LOAD_CONST instructions.
2. Calling a function with keyword arguments no longer needs EXTENDED_ARG.
3. The number of positional and keyword arguments is no longer limited by 255 (at least not in the bytecode).
4. The bytecode looks simpler, oparg always is just the number of arguments taken from the stack.

This proposition was discussed on Python-Ideas [2].

[1] http://permalink.gmane.org/gmane.comp.python.ideas/39993
[2] http://comments.gmane.org/gmane.comp.python.ideas/39961
msg267341 - (view) Author: Demur Rumed (Demur Rumed) * Date: 2016-06-04 23:12
I'd like to take on creating a patch for this proposal once #27140 lands
msg268285 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2016-06-11 21:51
I was going to write a patch myself, but since I'm sure in your skills, I yield it to you.
msg268652 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2016-06-16 09:37
Do you take this for your Demur?
msg268720 - (view) Author: Demur Rumed (Demur Rumed) * Date: 2016-06-17 11:35
I've been working on this, may have the ceval portion mostly worked out but can't test until I finish the compile portion. Haven't had time this week, will have time to focus this weekend
msg268860 - (view) Author: Demur Rumed (Demur Rumed) * Date: 2016-06-19 17:38
Attaching first iteration. Very drafty. Still need to fix test_dis; will run test suite this evening. Perf on pybench went from 16.5s to 17.5s. It was 18.3s prior to reintroducing use of fast_function. Code still needs clean up besides investigation into how to optimize

Changes not described in the original patch concept: I made CALL_FUNCTION_EX oparg carry 2 flag bits on whether there's a kwdict or a vararg tuple. Code may be simpler to only have kwdict be optional. BUILD_MAP_UNPACK_WITH_CALL was modified to only use the highest bit of the 2nd byte to track where function_pos is. Most uses of BUILD_MAP_UNPACK_WITH_CALL is f(*va,**kw) so I chose to only set the highest bit when there isn't a positional unpacking. If we pushed an empty tuple then that flag bit could be removed
msg268862 - (view) Author: Mark Shannon (Mark.Shannon) * Date: 2016-06-19 18:42
I seemed to have been added to the nosy list. I guess that means that my opinions are wanted ;)

I have wanted to clean up the code around making calls for quite a while. I just haven't had time.

I agree that adding a simpler opcode for making calls with positional only args is worthwhile.
However creating the tuple and/or dict at every call site is going to lead to slow downs. It gets even worse for bound-methods, as yet another tuple will need to be created to accommodate self.

What I would suggest is a new internal calling convention which embodies the six-part form of CALL_FUNCTION_VAR_KW, that is (number-of-postionals, pointer-to-positionals, number-of-keywords, pointer-to-keywords, starargs-tuple, doublestarargs-dict). 
As a first step, each of the four current CALL_FUNCTION variants could then call this function, filling in the relevant parameters.

The new function would look something like this:
PyEval_Call_Callable(
PyObject *callable,
int npos,
PyObject **positionals,
int nkws,
PyObject **keywords,
PyObject *starargs,
PyObject *dictargs) {
    if (Is_PyFunction(callable))
        return PyFunction_Call(callable, npos, ...);

    if (Is_CFunction(callable))
        return CFunction_Call(callable, npos, ...);

    // Otherwise general object...

    // We might want PyType_Call as well, since object creation is
    // another common form of call.

    // Create tuple and dict from args.
    return PyObject_Call(callable, tuple, dict);
}

This would mean that the logic for frame creation would be where it belongs (in the code for the Function object) and that special casing the various forms of CFunctions could be moved to where that belongs.

Given what Serhiy says about calls with just positional parameters being by far the most common, it sounds as if it would make sense to add 
PyFunction_CallSimple(PyObject *callable, int npos, PyObject**args)
and 
CFuntion_CallSimple(PyObject *callable, int npos, PyObject**args) 
variants for the new CALL_FUNCTION opcode to use.

With those changes, it would then make sense to replace the four opcodes
CALL_FUNCTION, CALL_FUNCTION_VAR, CALL_FUNCTION_KW, CALL_FUNCTION_VAR_KW

with 
CALL_FUNCTION -- As Serhiy suggests
CALL_FUNCTION_KW -- As Serhiy suggests
CALL_FUNCTION_VAR_KW -- As currently exists
msg268907 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2016-06-20 15:45
Thank you Demur. I left few comments on Rietveld (this is only the quick glance).

Good news that this change allows to simplify BUILD_MAP_UNPACK_WITH_CALL. But using 15th bit means using EXTENDED_ARG. I think it would be simpler to just push an empty tuple with LOAD_CONST. The same number of opcodes, but simpler implementation and nicer disassemble output.

Mark's idea about using oparg of the general variant for specifying a number of positional arguments without packing them in a tuple looks interesting. But I don't bother about this case. According to the statistics of running CPython tests *args or *kwargs are used only in 0.4% of calls. This is hardly worth optimizing. I'm going to collect more detailed statistics for number of args and function/method distinguishing.

As about PyFunction_CallSimple() etc, see issue26814 and issue27128. _PyObject_FastCall() protocol and new calling protocol should cover the case of new CALL_FUNCTION and may be CALL_FUNCTION_KW (>99% of calls in sum).
msg268948 - (view) Author: Demur Rumed (Demur Rumed) * Date: 2016-06-20 23:45
callfunc2 fixes test_dis, addresses code review, currently implements a copy of _PyEval_EvalCodeWithName as _PyEval_EvalCodeWithName2 which changes a few lines to work with new keyword stack layout so that we can use fast_function with kwargs

CALL_FUNCTION_EX is benchmarking much slower (4x slower when using **kw), but unpatched hits similar perf when using multiple **kw. So most slowdown is due to BUILD_MAP_UNPACK_WITH_CALL being slow. So some patch which speeds up intersection check (eg optimize to not allocate intersection when disjoint) should greatly diminish the perf loss on this simpler implementation. I'll open a separate issue for this
msg268998 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2016-06-21 13:50
Issue27358 is too complex, more complex than this issue. But I think the simple fix the regression in case of the single **kw is checking wherever the sum dict is empty.

-                if (with_call) {
+                if (with_call && PyDict_Size(sum)) {
msg269623 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2016-06-30 19:47
Added comments on Rietveld.
msg269669 - (view) Author: Demur Rumed (Demur Rumed) * Date: 2016-07-01 14:10
callfunc3 addresses most feedback. Doesn't address _PyEval_EvalCodeWithName2 code bloat, & I disagree with mentioning BUILD_MAP_UNPACK_WITH_CALL change in magic number update as the ABI of BUILD_MAP_UNPACK_WITH_CALL is unchanged. ie if we were to implement #27358 after this there would be no need to bump the magic number

One thing which looks odd to me is the INCREF/DECREF calls on function objects surrounding calls. Especially odd is CALL_FUNCTION_EX where we finish with two calls to Py_DECREF(func). It shows up in IMPORT_NAME too
msg269696 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2016-07-01 21:11
The ABI of BUILD_MAP_UNPACK_WITH_CALL is changed. oparg=514 meant merging 2 dicts, but with the patch it will mean merging 514 dicts.

The INCREF/DECREF calls on function objects surrounding calls are not needed, because the refcount was increased when the function pushed on the stack. They were needed if use PyMethod optimization, since PyMethod_GET_FUNCTION() returns borrowed link.

Seems you have missed my comments on compile.c.

Added more comments on Rietveld.

What about CALL_FUNCTION_EX benchmarking? Did the optimization help?
msg270064 - (view) Author: Demur Rumed (Demur Rumed) * Date: 2016-07-09 20:02
Pybench is now only ~200ms slower instead of 1200ms slower. But the whole point of this patch is that CALL_FUNCTION_EX shouldn't be optimized for, so I'd much prefer real benchmarking results
msg270521 - (view) Author: Demur Rumed (Demur Rumed) * Date: 2016-07-15 23:22
Since the most common use of CALL_FUNCTION_EX is..

def f(*x,*kw):
    other_func(*x, **kw)

I've added some code to BUILD_MAP_UNPACK_WITH_CALL & BUILD_TUPLE_UNPACK to not allocate a new object if called with oparg of 1 & TOP() is correct type
msg273372 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2016-08-22 13:05
See also the issue #27809 "_PyObject_FastCall(): add support for keyword arguments" where we discuss if we can completely avoid the creation of a temporary dictionary to pass keyword arguments.
msg273684 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2016-08-25 22:03
> Pybench is now only ~200ms slower instead of 1200ms slower. But the whole point of this patch is that CALL_FUNCTION_EX shouldn't be optimized for, so I'd much prefer real benchmarking results

FYI I released a first version of the "new" Python benchmark suite: performance 0.1 (quickly fixed with performance 0.1.1):

* https://pypi.python.org/pypi/performance
* https://github.com/python/benchmarks

The README file contains a few information how to run a stable benchmark. Please help me to complete this documentation :-)

I may help you to run these benchmarks.
msg273685 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2016-08-25 22:27
I'm working on a new calling convention: "fast call".

I already pushed changes implementing first functions:

_PyObject_FastCallDict(PyObject *func, PyObject **stack, Py_ssize_t nargs, PyObject *kwargs)

kwargs is a Python dict, but it can be NULL.

_PyObject_FastCallDict() avoids the creation a temporary tuple when you don't have to pass keyword arguments.

But I'm interested by an evolution to avoid also the creation of a temporary dictionary: issue #27830, "Add _PyObject_FastCallKeywords(): avoid the creation of a temporary dictionary for keyword arguments". This function would be the fundation for a new calling convention for C functions: #27810, "Add METH_FASTCALL: new calling convention for C functions".

I didn't read your patch carefully, but I would like to make sure that your patch would benefit of these APIs to avoid the creation of temporary tuple and/or dict.

"func(*args, key=value)" uses CALL_FUNCTION_EX and so requires to create a temporary dictionary. Maybe it's ok, I don't think that this syntax is commonly used.

"func(*args)" uses CALL_FUNCTION_EX: if args is a tuple, can you confirm that it would be possible to use _PyObject_FastCallDict() and/or _PyObject_FastCallKeywords() to avoid the creation a new temporary tuple?

Hum, I don't think that "func(*args)" can be optimized if args is a list because a list is mutable, we cannot use a direct access to the internal C array of a list.
msg274641 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2016-09-06 22:16
I uploaded callfunc-6.patch which is supposed to be a rebased version of callfunc5.patch. I made tiny coding style changes.

Python/ceval.c changed a lot since 1 month 1/2, so I'm not 100% sure that the rebase is correct.

Known issues:

* test_traceback and test_extcall fail
* _PyEval_EvalCodeWithName2() should be merged into _PyEval_EvalCodeWithName() to factorize the code

I didn't review the change yet.
msg275259 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2016-09-09 05:07
Rebased change.
msg275261 - (view) Author: Yury Selivanov (yselivanov) * (Python committer) Date: 2016-09-09 05:14
Serhiy, Victor and I want this to be merged tomorrow morning PST to land in 3.6 before the freeze.  Would you be able to merge this yourself?  If not, we'll do it ourselves in the morning.
msg275264 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2016-09-09 05:47
> Known issues:
> * test_traceback and test_extcall fail
> * _PyEval_EvalCodeWithName2() should be merged into _PyEval_EvalCodeWithName() to factorize the code

I fixed test_extcall and removed _PyEval_EvalCodeWithName2(): callfunc-8.patch.

I don't know how to fix test_traceback.

@Serhiy: I really need the patch tomorrow. Would you mind to push it? If you are unable to fix test_traceback, just skip the test with a FIXME and open a new issue (it should be easy to fix it later).

I really want to finish METH_FASTCALL, issue #27810, before the first beta next monday and basically tomorrow is for me the last time when I can still push things.

If we really find a major design issue, you still have 3 to 4 months to revert the change. If we find a minor design flaw or another optimization, again, we will still have time to enhance the code during the beta stage. The most important part is to push the major change to reduce changes after the first beta.
msg275295 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2016-09-09 09:39
I'm going to push the patch today. But changes to test_extcall look as a regression to me.
msg275348 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2016-09-09 16:56
> I'm going to push the patch today.

I'm going to push the patch in ~10 min since I don't see it pushed yet.

> But changes to test_extcall look as a regression to me.

I agree that it looks like a regression, but it might be tricky to
retrieve the function name from the stack. I'm not even sure that the
function name is always already on the stack.

Again, I have to rush before of the feature freeze, but I hope that we
will find a smart solution for this error message.
msg275351 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2016-09-09 17:11
Please wait. I just have sat down at my computer.
msg275352 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2016-09-09 17:13
> Please wait. I just have sat down at my computer.

Oh, you are here :-) Go ahead!
msg275372 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2016-09-09 18:23
> Please wait. I just have sat down at my computer.

Can you please give me a status and/or an ETA? This change is blocking me for 2 more changes.
msg275387 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2016-09-09 18:50
I just fixed test_extcall and test_traceback, and going to get rid of the 
duplication in _PyEval_EvalCodeWithName. I need maybe a hour or two.
msg275388 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2016-09-09 18:52
> I just fixed test_extcall and test_traceback, and going to get rid of the  duplication in _PyEval_EvalCodeWithName. I need maybe a hour or two.

What do you mean? I already fixed test_extcall and code duplication?

"I fixed test_extcall and removed _PyEval_EvalCodeWithName2(): callfunc-8.patch."

I proposed to skip the failing test in test_traceback and fix it after the beta release, I don't think that it's a major issue, it can be fixed later.

Can you please push callfunc-8.patch right now (skipping failing tests in test_traceback).
msg275402 - (view) Author: Roundup Robot (python-dev) Date: 2016-09-09 19:28
New changeset a77756e480c2 by Victor Stinner in branch 'default':
Rework CALL_FUNCTION* opcodes
https://hg.python.org/cpython/rev/a77756e480c2
msg275405 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2016-09-09 19:33
I'm really sorry Serhiy that I didn't give you more time to finish the review and push yourself the change :-( Feel free to enhance the code, I don't expect major changes.

For test_traceback, I opened the issue #28050: if you already know how to fix it, please go ahead ;-)
msg275409 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2016-09-09 19:48
You changed the test. I made the code passing unchanged test (in additional 
the bytecode for f(*a) and f(**kw) becomes simpler). _PyEval_EvalCodeWithName 
still contained large duplicated part. It can be removed.

Here is my current patch.
msg275411 - (view) Author: Roundup Robot (python-dev) Date: 2016-09-09 19:50
New changeset 854b08acca97 by Victor Stinner in branch 'default':
Issue #27213: document changes in Misc/NEWS
https://hg.python.org/cpython/rev/854b08acca97
msg275412 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2016-09-09 19:51
I just pushed my patch for the issue #27830 (add _PyObject_FastCallKeywords()). I'm trying to even push the first parts of METH_FASTCALL (issue #27810).

Could you please try to rebase callfunc-9.patch on top of the development branch? The code is moving soooo fast this week :-/
msg275448 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2016-09-09 21:23
Here is rebased patch.
msg275452 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2016-09-09 21:36
> Here is rebased patch.

callfunc-10.patch looks like an even better enhancement compared to Python 3.5, nice work. Would you be ok to wait after the beta1 release? The change doesn't seem to change the bytecode too much, nor the C API, whereas I'm trying to push a few other changes for FASTCALL.

Moreover, I didn't understand fully the change, I left some questions.
msg275748 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2016-09-11 08:55
I'm getting segfaults with a77756e480c2 (thanks to 'hg bisect') on Ubuntu 12.04. I've checked buildbots, but they seem happy.

In test_sys:

test_recursionlimit_recovery (test.test_sys.SysModuleTest) ... Fatal Python error: Segmentation fault

In test_runpy:

test_main_recursion_error (test.test_runpy.RunPathTestCase) ... Fatal Python error: Segmentation fault

I'm also getting the following error with Serhiy's latest patch:

python: Objects/abstract.c:2385: _PyStack_AsDict: Assertion `PyDict_GetItem(kwdict, key) != ((void *)0)' failed.
Aborted (core dumped)
generate-posix-vars failed
make: *** [pybuilddir.txt] Error 1
msg275749 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2016-09-11 09:01
Author: Berker Peksag (berker.peksag) * (Python committer) 	Date: 2016-09-11 08:55

Berker: "I'm getting segfaults with a77756e480c2 (thanks to 'hg bisect') on Ubuntu 12.04 (...)
test_recursionlimit_recovery (...) test_main_recursion_error (...)"

We should check if the change counts correctly the number of frames.

In callfunc-10.patch, Serhiy modified a counter related to recursion limit/number of frames to fix test_traceback (issue #28050). He wrote on the review:

"Seems the number 50 is arbitrary. Now we should increase it. Why? This issue needs further investigation. Maybe this is a sign of regression."

To me, it's suspicious that we have to modify an unit test. Changing the opcode or internals must not have an impact on unit tests on recursion error.

Note: It might also be related to my FASTCALL changes, but you wrote that "hg bisect" pointed you to this change.


Berker: "I'm also getting the following error with Serhiy's latest patch: python: Objects/abstract.c:2385: _PyStack_AsDict: Assertion `PyDict_GetItem(kwdict, key) != ((void *)0)' failed."

This one might be related to the compact dict change.


Note: Just to make be sure that it is not a local issue, please try a "make distclean" and make sure that all .pyc files are removed, and then recompile Python.
msg275752 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2016-09-11 09:10
> [...] please try a "make distclean" and make sure that all .pyc files are removed, and then recompile Python.

I forgot to mention that in my earlier comment. I usually run "make distclean" before "./configure --with-pydebug; make -s -j" so unfortunately running "make distclean" didn't help.
msg275766 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2016-09-11 10:07
> python: Objects/abstract.c:2385: _PyStack_AsDict: Assertion
> `PyDict_GetItem(kwdict, key) != ((void *)0)' failed. Aborted (core dumped)
> generate-posix-vars failed
> make: *** [pybuilddir.txt] Error 1

Ah, it's my fault. I didn't test the latest patch with debug build. Here should be == instead of !=. Could you please test updated patch? Unfortunately I can's reproduce crashes in test_sys and test_runpy (on 32-bit Linux).
msg275770 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2016-09-11 10:35
Thanks, Serhiy.

test_recursionlimit_recovery in test_sys passed, but now I'm getting the following failure:

FAIL: test_recursionlimit_fatalerror (test.test_sys.SysModuleTest)

I modified test_recursionlimit_fatalerror to use subTest() and it looks like the test passed when sys.setrecursionlimit(50). See i=1000 in the following output:

======================================================================
FAIL: test_recursionlimit_fatalerror (test.test_sys.SysModuleTest) (i=1000)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/berker/hacking/cpython/default/Lib/test/test_sys.py", line 283, in test_recursionlimit_fatalerror
    err)
AssertionError: b'Fatal Python error: Cannot recover from stack overflow' not found in b''

----------------------------------------------------------------------

test_runpy still segfaults:

test_main_recursion_error (test.test_runpy.RunPathTestCase) ... Fatal Python error: Segmentation fault

I wrote a quick and dirty reproducer for this. I can attach here if you think it would be useful for debugging.
msg275784 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2016-09-11 12:46
Please attach a reproducer Berker. I still can't reproduce crashes. Maybe it depends on platform or installed third-party module or Python command line options.
msg275861 - (view) Author: Roundup Robot (python-dev) Date: 2016-09-11 21:53
New changeset 51b635e81958 by Serhiy Storchaka in branch 'default':
Issue #27213: Fixed different issues with reworked CALL_FUNCTION* opcodes.
https://hg.python.org/cpython/rev/51b635e81958
msg275885 - (view) Author: Robert Collins (rbcollins) * (Python committer) Date: 2016-09-11 23:27
See http://bugs.python.org/issue28086 - this introduced a regression in the test suite.
msg276004 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2016-09-12 08:52
I have committed the patch before beta 1 because it change bytecode generating and interpreting. The bytecode generated before the patch is compatible with the patched interpreter, but the bytecode generated by patched compiler can be not compatible with unpatched interpreter. After releasing beta 1 this would require changing bytecode magic number.
msg276006 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2016-09-12 09:04
The change 51b635e81958 introduced memory leaks. Example:

$ ./python -m test -R 3:3 test_extcall
(...)
test_extcall leaked [102, 102, 102] references, sum=306
test_extcall leaked [41, 41, 41] memory blocks, sum=123

I'm analyzing the change to try to identify leaks.
msg276008 - (view) Author: Roundup Robot (python-dev) Date: 2016-09-12 09:17
New changeset f217419d08f0 by Victor Stinner in branch 'default':
Issue #27213: Fix reference leaks
https://hg.python.org/cpython/rev/f217419d08f0
msg276021 - (view) Author: Roundup Robot (python-dev) Date: 2016-09-12 11:04
New changeset f860b7a775c5 by Victor Stinner in branch 'default':
ssue #27213: Reintroduce checks in _PyStack_AsDict()
https://hg.python.org/cpython/rev/f860b7a775c5
msg276022 - (view) Author: Roundup Robot (python-dev) Date: 2016-09-12 11:38
New changeset e372c0ad32ce by Victor Stinner in branch 'default':
Revert change f860b7a775c5
https://hg.python.org/cpython/rev/e372c0ad32ce

New changeset 2558bc4a4ebf by Victor Stinner in branch 'default':
Document kwnames in _PyObject_FastCallKeywords() and _PyStack_AsDict()
https://hg.python.org/cpython/rev/2558bc4a4ebf
msg276063 - (view) Author: Yury Selivanov (yselivanov) * (Python committer) Date: 2016-09-12 15:59
>  After releasing beta 1 this would require changing bytecode magic number.

Why don't we change the magic number before b1 (if your bytecode change is already committed)?
msg276064 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2016-09-12 16:14
> Why don't we change the magic number before b1 (if your bytecode change is already committed)?

The magic number changed many times between Python 3.5 and the future Python 3.6 beta 1. Maybe we skipped increasing this number for one bytecode change, but it should only impact the few developers who worked on the development version. In this case: just remove all ".pyc" files and it should be fine ;-)

In short: I think it's fine, don't do anything else ;-)
msg276073 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2016-09-12 17:19
Objects/methodobject.c: In function ‘_PyCFunction_FastCallKeywords’:
Objects/methodobject.c:281:24: warning: ‘nkwargs’ may be used uninitialized in this function [-Wmaybe-uninitialized]
     assert((nargs == 0 && nkwargs == 0) || stack != NULL);
                        ^
msg276102 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2016-09-12 19:55
Thanks for the report, warning fixed in the issue #28105.
msg277233 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2016-09-22 16:54
I think that's all with this issue.
msg277239 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2016-09-22 21:13
> I think that's all with this issue.

Thanks Demur and Serhiy for your great work!
History
Date User Action Args
2016-09-22 21:13:20hayposetmessages: + msg277239
2016-09-22 16:54:56serhiy.storchakasetstatus: open -> closed
resolution: fixed
messages: + msg277233

stage: patch review -> resolved
2016-09-12 19:55:04hayposetmessages: + msg276102
2016-09-12 17:19:26serhiy.storchakasetmessages: + msg276073
2016-09-12 16:14:13hayposetmessages: + msg276064
2016-09-12 15:59:36yselivanovsetmessages: + msg276063
2016-09-12 11:38:51python-devsetmessages: + msg276022
2016-09-12 11:04:30python-devsetmessages: + msg276021
2016-09-12 09:17:34python-devsetmessages: + msg276008
2016-09-12 09:04:10hayposetmessages: + msg276006
2016-09-12 08:52:06serhiy.storchakasetmessages: + msg276004
2016-09-11 23:27:27rbcollinssetnosy: + rbcollins
messages: + msg275885
2016-09-11 21:53:25python-devsetmessages: + msg275861
2016-09-11 16:43:52serhiy.storchakasetfiles: - IMG_20160830_174452.jpg
2016-09-11 16:40:35Влад Ключкейsetfiles: + IMG_20160830_174452.jpg
hgrepos: + hgrepo354
2016-09-11 12:46:38serhiy.storchakasetmessages: + msg275784
2016-09-11 10:35:56berker.peksagsetmessages: + msg275770
2016-09-11 10:07:45serhiy.storchakasetfiles: + callfunc-12.patch

messages: + msg275766
2016-09-11 09:10:59berker.peksagsetmessages: + msg275752
2016-09-11 09:01:17hayposetmessages: + msg275749
2016-09-11 08:55:24berker.peksagsetnosy: + berker.peksag
messages: + msg275748
2016-09-11 06:29:47serhiy.storchakasetfiles: + callfunc-11.patch
2016-09-10 03:36:41haypounlinkissue27830 dependencies
2016-09-09 21:36:49hayposetmessages: + msg275452
2016-09-09 21:23:33serhiy.storchakasetfiles: + callfunc-10.patch

messages: + msg275448
2016-09-09 19:51:35hayposetmessages: + msg275412
2016-09-09 19:50:29python-devsetmessages: + msg275411
2016-09-09 19:48:20serhiy.storchakasetfiles: + callfunc-9.patch

messages: + msg275409
2016-09-09 19:33:39hayposetmessages: + msg275405
2016-09-09 19:28:41python-devsetnosy: + python-dev
messages: + msg275402
2016-09-09 18:52:33hayposetmessages: + msg275388
2016-09-09 18:50:21serhiy.storchakasetmessages: + msg275387
2016-09-09 18:23:52hayposetmessages: + msg275372
2016-09-09 17:13:59hayposetmessages: + msg275352
2016-09-09 17:11:58serhiy.storchakasetmessages: + msg275351
2016-09-09 16:56:23hayposetmessages: + msg275348
2016-09-09 09:39:50serhiy.storchakasetassignee: serhiy.storchaka
2016-09-09 09:39:41serhiy.storchakasetmessages: + msg275295
2016-09-09 05:47:39hayposetfiles: + callfunc-8.patch

messages: + msg275264
2016-09-09 05:14:29yselivanovsetnosy: + yselivanov
messages: + msg275261
2016-09-09 05:07:56hayposetfiles: + callfunc-7.patch

messages: + msg275259
2016-09-06 22:16:14hayposetfiles: + callfunc-6.patch

messages: + msg274641
2016-08-25 22:27:13hayposetmessages: + msg273685
2016-08-25 22:03:17hayposetmessages: + msg273684
2016-08-25 21:34:54haypolinkissue27830 dependencies
2016-08-22 13:05:26hayposetmessages: + msg273372
2016-07-15 23:22:09Demur Rumedsetfiles: + callfunc5.patch

messages: + msg270521
2016-07-09 20:02:22Demur Rumedsetfiles: + callfunc4.patch

messages: + msg270064
2016-07-01 21:11:46serhiy.storchakasetmessages: + msg269696
2016-07-01 14:10:52Demur Rumedsetfiles: + callfunc3.patch

messages: + msg269669
2016-06-30 19:47:31serhiy.storchakasetmessages: + msg269623
2016-06-21 13:50:26serhiy.storchakasetmessages: + msg268998
2016-06-20 23:45:47Demur Rumedsetfiles: + callfunc2.patch

messages: + msg268948
2016-06-20 15:45:41serhiy.storchakasetnosy: + haypo
messages: + msg268907
2016-06-19 22:08:13serhiy.storchakasetstage: patch review
2016-06-19 18:42:49Mark.Shannonsetmessages: + msg268862
2016-06-19 17:38:15Demur Rumedsetfiles: + callfunc.patch
keywords: + patch
messages: + msg268860
2016-06-17 11:35:34Demur Rumedsetmessages: + msg268720
2016-06-16 09:37:32serhiy.storchakasetmessages: + msg268652
2016-06-11 21:51:32serhiy.storchakasetmessages: + msg268285
2016-06-04 23:12:07Demur Rumedsetmessages: + msg267341
2016-06-04 21:06:49serhiy.storchakasetnosy: + Mark.Shannon, Demur Rumed
2016-06-04 07:46:00serhiy.storchakasetdependencies: + Opcode for creating dict with constant keys
2016-06-04 07:45:34serhiy.storchakacreate