wrong error messages when using PyArg_ParseTuple to parse normal tuples

[orenmn]

BPO	28261
Nosy	@rhettinger, @vstinner, @serhiy-storchaka, @orenmn
PRs	bpo-28261: fix err msgs where PyArg_ParseTuple is used to parse normal tuples #3119 bpo-28261: fix err msgs where PyArg_ParseTuple is used to parse normal tuples (leftovers) #3198 [3.6] bpo-28261: Prevent raising SystemError where PyArg_ParseTuple is used to parse non-args #3210 [2.7] bpo-28261: Prevent raising SystemError where PyArg_ParseTuple is used to parse non-args #3213
Files	testBugsOrPatches.py: an ugly script that verifies the bugs or the patches issue28261_ver1.diff: proposed patches diff file - ver1 patchedCPythonTestOutput_ver1.txt: test output of CPython with my patches (tested on my PC) - ver1 CPythonTestOutput.txt: test output of CPython without my patches (tested on my PC)

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/serhiy-storchaka'
closed_at = <Date 2017-08-26.19:01:58.457>
created_at = <Date 2016-09-23.20:16:55.347>
labels = ['type-bug', '3.7', 'expert-IO']
title = 'wrong error messages when using PyArg_ParseTuple to parse normal tuples'
updated_at = <Date 2017-08-26.19:01:58.455>
user = 'https://github.com/orenmn'

bugs.python.org fields:

activity = <Date 2017-08-26.19:01:58.455>
actor = 'serhiy.storchaka'
assignee = 'serhiy.storchaka'
closed = True
closed_date = <Date 2017-08-26.19:01:58.457>
closer = 'serhiy.storchaka'
components = ['IO']
creation = <Date 2016-09-23.20:16:55.347>
creator = 'Oren Milman'
dependencies = []
files = ['44795', '44796', '44797', '44798']
hgrepos = []
issue_num = 28261
keywords = ['patch']
message_count = 22.0
messages = ['277296', '288792', '288861', '288862', '288869', '288911', '288917', '289672', '289673', '289727', '300366', '300402', '300417', '300418', '300604', '300614', '300792', '300841', '300843', '300875', '300893', '300896']
nosy_count = 4.0
nosy_names = ['rhettinger', 'vstinner', 'serhiy.storchaka', 'Oren Milman']
pr_nums = ['3119', '3198', '3210', '3213']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue28261'
versions = ['Python 3.7']

[orenmn]

------------ current state ------------
In few places in the codebase, PyArg_ParseTuple is called in order to parse a normal tuple (instead of the usual case of parsing the arguments tuple of a function).
In some of these places, failure of PyArg_ParseTuple is handled simply by cleanup (if needed) and returning an error code, and so an exception with the generic error message is raised.
The generic error message is appropriate in case the parsed tuple is the arguments tuple of a function, but might be really wrong in case it is a normal tuple.

For example, such case in Modules/socketmodule.c in socket_getnameinfo leads to the following:
    >>> import socket
    >>> socket.getnameinfo(tuple(), 1)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: function takes at least 2 arguments (0 given)
    >>>

------------ proposed changes ------------
In each of these places, add to the format string (which is passed to PyArg_ParseTuple) a ';', followed by an appropriate error message, as already done in Modules/audioop.c in audioop_ratecv_impl:
if (!PyArg_ParseTuple(state,
"iO!;audioop.ratecv: illegal state argument",
&d, &PyTuple_Type, &samps))
goto exit;

------------ diff ------------
The proposed patches diff file is attached.

------------ tests ------------
I wrote an ugly script to verify the wrong error messages on CPython without my patches, and to test the patches on CPython with my patches. The script is attached (but it might fail on a non-Windows machine).

In addition, I ran 'python_d.exe -m test -j3' (on my 64-bit Windows 10) with and without the patches, and got quite the same output.
The outputs of both runs are attached.

[vstinner]

I dislike passing a error message in the function name. I suggest to instead raise a new exception with a better error message and chain it with the previous exception.

[orenmn]

Do you mean that in each case PyArg_ParseTuple fails, we should chain
to the exception raised by PyArg_ParseTuple an exception that specifies
the name of the tuple that PyArg_ParseTuple failed to parse, without
specifying the function name?

[serhiy-storchaka]

An error message is not passed in the function name. PyArg_ParseTuple() allows you to pass an arbitrary error message. I think this feature is specially designed for these cases.

I didn't look the patch close, but Oren's approach LGTM in general.

[serhiy-storchaka]

Oren, could you write reproducers for all affected cases? I don't think we need to add them as regular tests, but we should be able to check changes manually.

There are conflicts in Modules/itertoolsmodule.c.

[rhettinger]

-0 The new code looks awful, and in the case of the itertools module, these are messages that users are unlikely to see (the methods are typically only called by pickle, and pickling itself is rare for itertools).

[serhiy-storchaka]

Would it look less awful if remove "xxxxxx.__setstate__: "?

[orenmn]

Raymond? any suggestions for how to make the code less ugly?
or do you have in mind a different approach for solving this issue?

[serhiy-storchaka]

I suggest to withdraw changes in itertoolsmodule.c and avoid using "dunder" names like __setstate__ and __new__ in error messages.

[orenmn]

as Serhiy pointed out in PR 668, here are some more functions that produce the
same kind of wrong error messages:
- Modules/timemodule.c - gettmarg()
- Modules/socketmodule.c:
* getsockaddrarg()
* socket_getnameinfo()

ISTM that searching for 'PyTuple_Check(' might be a good way to find more such
functions, as they sometimes raise an error in case a type other than tuple was
received (and after that, PyArg_ParseTuple is called).

[orenmn]

I replied to your comments in Rietveld, Serhiy. (http://bugs.python.org/review/28261)

also, i found two places with a quite similar issue:
- in Objects/exceptions.c in ImportError_init:
    >>> ImportError(1, 2, 3, 4, a=5, b=6, c=7)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: ImportError() takes at most 2 arguments (3 given)
- in Python/bltinmodule.c in min_max:
    >>> min(1, 2, 3, 4, a=5, b=6, c=7)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: function takes at most 2 arguments (3 given)

may I fix them also as part of this issue?