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 Dormouse759
Recipients Dormouse759, cstratak, ishcherb, pablogsal, serhiy.storchaka, vstinner
Date 2018-06-18.15:28:22
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
The problem is with this function:
static PyObject *
builtin_id(PyModuleDef *self, PyObject *v)
/*[clinic end generated code: output=0aa640785f697f65 input=5a534136419631f4]*/
    return PyLong_FromVoidPtr(v);

It's a one-liner, so the compiler really likes to inline it.

Without the inline optimization, the additional "next" command makes a jump into the function.

But when the function is inlined and you set a breakpoint to it, the line is just seen as a function from the debugger, that means you already are inside and the "next" makes the debugger exit this line, and so the function.

More graphical explanation:
non-inline case:
   return PyLong_FromVoidPtr(v);

inline case:
   return PyLong_FromVoidPtr(v);
"Some code without access to the func arguments' debug symbols"

I propose two possible solutions:
1) Skip whole test_gdb when optimizations are used (who debugs with them anyway?)
2) Conditionalize the "next". (this could be hard as we would need to know when the function is inlined)

Also, I have found out that when configured with --with-pydebug and --enable-optimizations, tests stop to fail. (the failing bots are configuring with --enable-optimizations only)
Date User Action Args
2018-06-18 15:28:23Dormouse759setrecipients: + Dormouse759, vstinner, serhiy.storchaka, cstratak, ishcherb, pablogsal
2018-06-18 15:28:23Dormouse759setmessageid: <>
2018-06-18 15:28:23Dormouse759linkissue32962 messages
2018-06-18 15:28:22Dormouse759create