Message319888
| 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) |
|