Title: nb_inplace_pow is always called with an invalid argument
Type: crash Stage: patch review
Components: Build, Extension Modules Versions: Python 3.8, Python 3.7, Python 2.7
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: ZackerySpytz, Zuzu_Typ, josh.r, miss-islington, rhettinger, skrah
Priority: normal Keywords: patch

Created on 2019-03-20 12:01 by Zuzu_Typ, last changed 2020-08-24 04:26 by josh.r.

File name Uploaded Description Edit
Doesn't Work.png Zuzu_Typ, 2019-03-20 17:22
Pull Requests
URL Status Linked Edit
PR 13546 merged ZackerySpytz, 2019-05-24 13:14
Messages (10)
msg338458 - (view) Author: (Zuzu_Typ) Date: 2019-03-20 12:01
Using the C-API, the inplace_pow numbermethod is always called with the third argument pointing to an invalid address.

The reason is likely that self.__ipow__ only takes one argument, resulting in a binaryfunc (self, arg), though inplace_pow is a ternaryfunc.
When trying to use the third argument in any way, Python crashes.

The third arg should be nonexistent, NULL or Py_None.
msg338481 - (view) Author: Josh Rosenberg (josh.r) * (Python triager) Date: 2019-03-20 15:20
object.__ipow__ is documented to take an optional third argument (though there is no way to pass it aside from explicitly calling __ipow__ directly since there is no syntax support for three-arg pow, in place or otherwise), so it's not some incompatibility with object.__ipow__'s signature.

How are you seeing garbage passed? In the CPython C code base, I only see PyNumber_InPlacePower called in two places; ceval.c (to handle **=, which only handles two operands) and _operator.c (to implement operator.__ipow__, which unlike object.__ipow__, only takes two arguments, not three). In both cases, the third argument is explicitly passed in as Py_None.

PyNumber_InPlacePower itself then passes along that third argument to ternary_op as its third argument, and every code path that calls the retrieved slot consistently passes that argument along as the third argument to the slotted ternaryfunc.

I suppose an extension module might incorrectly call PyNumber_InPlacePower without passing the third argument, but that's a problem on their end (and should be caught by the compiler unless all diagnostics are suppressed).

But I'm not seeing the problem here. The code path is probably untested (given all numeric types in the CPython core are immutable, so none of them set nb_inplace_pow), but it looks correct at first glance. Do you have code that reproduces the error?
msg338500 - (view) Author: (Zuzu_Typ) Date: 2019-03-20 17:22
Even though __ipow__ might be documented to take a third argument, if you build an inplace_pow function using the C-API, you can only pass one argument to it.

You can see that in the attached screenshot.

The example class shown in the screenshot can be found here:

With the little template I wasn't able to reproduce the crash, but I did reassure myself that the third object is neither Py_None nor NULL, by adding "if (obj2 == Py_None || obj2 == NULL) return NULL;" before line 469 in "template.c", because calling __ipow__ still returned an example_class instance, instead of an error message, as it should if it returned NULL.
msg338502 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2019-03-20 17:36
Like Josh I don't quite understand the problem description. This
for example works:

>>> class C(int):
...     def __ipow__(self, other, mod=None):
...         return pow(self, other, mod)
>>> x = C(10)
>>> x
>>> x **= 3
>>> x
msg338503 - (view) Author: (Zuzu_Typ) Date: 2019-03-20 17:42
This isn't about the CPython Interpreter, it's about the C-API, the APIT for writing c-extensions for Python.

I know it works in CPython.
msg338504 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2019-03-20 18:27
Ok, got it. I think __ipow__ should be a ternaryfunc, like so:

diff --git a/Objects/typeobject.c b/Objects/typeobject.c
index 403f3caaee..914d076b5c 100644
--- a/Objects/typeobject.c
+++ b/Objects/typeobject.c
@@ -7032,7 +7032,7 @@ static slotdef slotdefs[] = {
     IBSLOT("__imod__", nb_inplace_remainder, slot_nb_inplace_remainder,
            wrap_binaryfunc, "%="),
     IBSLOT("__ipow__", nb_inplace_power, slot_nb_inplace_power,
-           wrap_binaryfunc, "**="),
+           wrap_ternaryfunc, "**="),
     IBSLOT("__ilshift__", nb_inplace_lshift, slot_nb_inplace_lshift,
            wrap_binaryfunc, "<<="),
     IBSLOT("__irshift__", nb_inplace_rshift, slot_nb_inplace_rshift,

On the other hand it is odd if "**=" can never use the third argument.
msg339353 - (view) Author: Josh Rosenberg (josh.r) * (Python triager) Date: 2019-04-02 17:59
skrah: Is there any reason your patch, as written, wouldn't work? If you need a test case to verify, gmpy2's xmpz type supports in place pow (but requires the modulus to be None, since there is no normal way to pass it anyway), so you can just test:

    >>> xm = gmpy2.xmpz(2)
    >>> xm.__ipow__(3, 5)

Right now, that code will raise a TypeError (from check_num_args in wrap_binary_func):

    TypeError: expected 1 argument, got 2


    >>> xm.__ipow__(3)

typically results in:

    SystemError: modulo not expected

because wrap_binaryfunc fails to pass the expected argument so the receiver sees garbage, and xmpz's ipow implementation checks the third argument raises an exception if anything but None is received; barring a coincidence of Py_None being on the stack there, it'll always fail the test.

Changing to wrap_ternaryfunc should make xm.__ipow__(3, 5) raise the SystemError currently raised by xm.__ipow__(3) (because it doesn't accept non-None), while xm.__ipow__(3) will work correctly.
msg343387 - (view) Author: Zackery Spytz (ZackerySpytz) * (Python triager) Date: 2019-05-24 13:44
I've created a PR for this issue (with tests).
msg344051 - (view) Author: miss-islington (miss-islington) Date: 2019-05-31 09:46
New changeset c7f803b08ed5211701c75f98ba9ada85d45ac155 by Miss Islington (bot) (Zackery Spytz) in branch 'master':
bpo-36379: __ipow__ must be a ternaryfunc, not a binaryfunc (GH-13546)
msg375835 - (view) Author: Josh Rosenberg (josh.r) * (Python triager) Date: 2020-08-24 04:26
Zackery, should this be closed? Or is there something missing from the patch?
Date User Action Args
2020-08-24 04:26:23josh.rsetmessages: + msg375835
2019-05-31 09:46:39miss-islingtonsetnosy: + miss-islington
messages: + msg344051
2019-05-24 13:44:29ZackerySpytzsetnosy: + ZackerySpytz
messages: + msg343387
2019-05-24 13:14:08ZackerySpytzsetkeywords: + patch
stage: needs patch -> patch review
pull_requests: + pull_request13458
2019-04-02 17:59:03josh.rsetmessages: + msg339353
versions: + Python 3.8
2019-03-20 18:29:38skrahsetstage: needs patch
2019-03-20 18:27:00skrahsetnosy: + rhettinger
messages: + msg338504
2019-03-20 17:42:23Zuzu_Typsetmessages: + msg338503
2019-03-20 17:36:02skrahsetnosy: + skrah
messages: + msg338502
2019-03-20 17:22:21Zuzu_Typsetfiles: + Doesn't Work.png

messages: + msg338500
2019-03-20 15:20:02josh.rsetnosy: + josh.r
messages: + msg338481
2019-03-20 12:01:33Zuzu_Typcreate