`type_getattro()` calls `tp_descr_get(self, obj, type)` without actually owning a reference to "self". In very rare cases, this can cause a segmentation fault if "self" is deleted by the descriptor.

Downstream: [http://trac.sagemath.org/ticket/19633]

This is a known general issue which is documented in Lib/test/crashers/borrowed_ref_1 inside the 2.7 branch.  In trunk, I see that this file has been deleted, although the issue has not been solved in general.  Only the particular crash in the file has been solved.  (Somebody with motivation should restore the crashers that have been solved superficially only.  But finding actual crashing code takes more effort than I'm willing to put into this rather pointless process, so CPython still gets the occasional bug report like this one instead.)

Thanks for the pointer. My patch does fix the crash in Lib/test/crashers/borrowed_ref_2.py on Python 2.7.10.

Will Jeroen's patch make it into 2.7.12 or are you expecting more stuff before committing a change?

I haven't seen any crashes in the wild here, but this is still the case in the latest code base. The change doesn't seem invasive, so I don't see why it shouldn't get implemented.

I cannot be 100% sure, but we have ample evidence suggesting we're experiencing this same crash in production.

We have a big system that mixes Cython and pure-python coroutines, and in one version we started seeing segfaults that strongly hint at this root cause.

Adding pure-python indirections (that keep the arguments alive, I'd wager), fixes those segfaults.

I cannot share the codebase (and in any case it's too big, and the crash is too difficult to reproduce in isolation, without real traffic), but I'd add my +1 on applying this fix.

We're currently testing to try and reproduce the segfaults on 2.7.13, after that I'll try jdemeyer's patch and report the results.

descr_ref-2.patch: patch rebased on the 2.7 branch.

Claudio: "We're currently testing to try and reproduce the segfaults on 2.7.13, after that I'll try jdemeyer's patch and report the results."

Cool! Keep us in touch ;-)

The crash (the one we're experiencing) still happens with 2.7.13. But at this point it's not clear whether it's a Python bug or a Cython bug, as jdemeyer's patch doesn't fix it. We're having a hard time getting accurate backtraces to actually debug this thing, as it only happens on production servers.

> The crash (the one we're experiencing) still happens with 2.7.13. But at this point it's not clear whether it's a Python bug or a Cython bug, as jdemeyer's patch doesn't fix it. We're having a hard time getting accurate backtraces to actually debug this thing, as it only happens on production servers.

I suggest you to try faulthandler to try to get a traceback ;-)

<shameless plug> If you are on POSIX, you could also use cysignals to get a traceback (simply import cysignals, which will install a handler for fatal signals like SIGSEGV).

Nice ideas, will give them a try

New changeset 8f735485acf2e35a75d2fa019feb8f905598c4e5 by Victor Stinner (jdemeyer) in branch 'master':
bpo-25750: fix refcounts in type_getattro() (GH-6118)
https://github.com/python/cpython/commit/8f735485acf2e35a75d2fa019feb8f905598c4e5

New changeset f862f3abaed59b83763707ae529f0fe487961ba9 by Miss Islington (bot) in branch '3.7':
bpo-25750: fix refcounts in type_getattro() (GH-6118)
https://github.com/python/cpython/commit/f862f3abaed59b83763707ae529f0fe487961ba9

New changeset 3ee07432f2e607cc6e7e6ea2d3695b672ceb1cea by Victor Stinner (Miss Islington (bot)) in branch '3.6':
bpo-25750: fix refcounts in type_getattro() (GH-6118) (GH-9088)
https://github.com/python/cpython/commit/3ee07432f2e607cc6e7e6ea2d3695b672ceb1cea

New changeset bf2bd8f8a1d88de60c114de957f50fe2433e3937 by Victor Stinner in branch '2.7':
bpo-25750: fix refcounts in type_getattro() (GH-6118) (GH-9091)
https://github.com/python/cpython/commit/bf2bd8f8a1d88de60c114de957f50fe2433e3937

The bug has been fixed in 2.7, 3.6, 3.7 and master branches. Thanks Jeroen Demeyer for your tenacity and hard work :-)

Let's see what we do with the unit test: PR 9084.

New changeset 5a30620e68ebb911eef4d583de3776d782148637 by Victor Stinner (jdemeyer) in branch 'master':
bpo-25750: Add test on bad descriptor __get__() (GH-9084)
https://github.com/python/cpython/commit/5a30620e68ebb911eef4d583de3776d782148637

This change introduced a compiler warning.

/home/serhiy/py/cpython/Modules/_testcapimodule.c:5042:17: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
     {"bad_get", bad_get, METH_FASTCALL},
                 ^~~~~~~
/home/serhiy/py/cpython/Modules/_testcapimodule.c:5042:17: note: (near initialization for ‘TestMethods[173].ml_meth’)

Comment on the commit:
https://github.com/python/cpython/commit/5a30620e68ebb911eef4d583de3776d782148637#commitcomment-31057082

"bad_get should be explicitly cast to PyCFunction here, or else the compiler will balk; see https://bugs.python.org/msg328176 "

The cast warning is not specific to this issue, it's a more general issue that will be address in bpo-33012. I close again  the bug.

bpo-33012 is about more strong warnings in gcc 8. This issue introduced a warning in gcc 7.

Is it necessary to use METH_FASTCALL?

> Is it necessary to use METH_FASTCALL?

In Python 3, the bug only occurs with METH_FASTCALL. The issue is a reference counting bug and the temporary tuple used for a METH_VARARGS method avoids the bug.

New changeset b1dede3ee3498100b95265f7fdb0ea2bef9a2ba2 by Serhiy Storchaka in branch 'master':
bpo-25750: Fix a compiler warning introduced in GH-9084. (GH-10234)
https://github.com/python/cpython/commit/b1dede3ee3498100b95265f7fdb0ea2bef9a2ba2