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 <1529335703.04.0.56676864532.issue32962@psf.upfronthosting.co.za>
In-reply-to
Content
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:
br
{
next
   return PyLong_FromVoidPtr(v);

inline case:
br
   return PyLong_FromVoidPtr(v);
next
"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)
History
Date User Action Args
2018-06-18 15:28:23Dormouse759setrecipients: + Dormouse759, vstinner, serhiy.storchaka, cstratak, ishcherb, pablogsal
2018-06-18 15:28:23Dormouse759setmessageid: <1529335703.04.0.56676864532.issue32962@psf.upfronthosting.co.za>
2018-06-18 15:28:23Dormouse759linkissue32962 messages
2018-06-18 15:28:22Dormouse759create