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)