Many tests in test_gdb are not run if python_is_optimized() is true. However, it's not entirely clear why we have this condition. For example, on my system, with the default CPython configuration, Python *is* optimized but still all gdb tests pass if I artificially enable them.

Maybe we need debug symbols, but the existence of debug symbols and optimization are orthogonal.

The tests FAIL when CPython is compiled with "-O0 -g0" (without optimizations, without debug info) but tests PASS when compiled with "-O3 -g", showing that the check for "-g" is the right one.

Depending on the compiler optimization level, gdb may or may not br able to read variables and function arguments. IHMO it is fine to skip test_gdb if Python "is optimized". I don't think it is worth it to check the exact optimizatio level.

The worst debugging experience is provided by PGO build.

> Depending on the compiler optimization level, gdb may or may not br able to read variables and function arguments.

I haven't seen that problem. As I said, all GDB tests pass when compiled with "-O3 -g".

> IHMO it is fine to skip test_gdb if Python "is optimized".

The fact that these GDB tests are not run in any CI build is bad. For example, we had a buildbot failure after merging PEP 590 because of this. We should try to catch test breakage as early as possible, the buildbot should be the last resort.

> I haven't seen that problem. As I said, all GDB tests pass when compiled with "-O3 -g".

Again, it depends on the optimization level, but IMHO it's not worth it to implement an heuristic to check if gdb has enough info to run tests.


> The fact that these GDB tests are not run in any CI build is bad.

gdb is not installed on Travis CI, but test_gdb is run on almost all buildbots.


> We should try to catch test breakage as early as possible, the buildbot should be the last resort.

Maybe open an issue to attempt to install gdb on Travis CI?

test_gdb breakage are quiet rare. If you modify code which can impact test_gdb, you can run test_gdb locally. Because breakages are rare, I never invested time on this issue: there are more blocking issues in my agenda ;-)

> If you modify code which can impact test_gdb, you can run test_gdb locally

I do run test_gdb locally but it's not very useful since most tests are skipped by default because python_is_optimized() is True. That's the whole point of this issue: tests are skipped without a good reason.

> I do run test_gdb locally but it's not very useful since most tests are skipped by default because python_is_optimized() is True.

Ah, I forgot to mention that I always compile Python using:

./configure -C --with-pydebug CFLAGS="-O0" && make

-O0 is not really needed, but sometimes -Og is too aggressive and fails to read some symbols. Or maybe it's just me who is not used to -Og yet :-)

I prefer -O0 because the compilation is way faster! But don't use this config for benchmarks ;-)

> The worst debugging experience is provided by PGO build.

That's true but unrelated to this issue. We already skip test_gdb completely when PGO is enabled.

> That's true but unrelated to this issue. We already skip test_gdb completely when PGO is enabled.

What do you mean? support.PGO is something different: it's only used while profiling Python before Python is recompiled a second time.

I meant this part in test_gdb.py:

if ((sysconfig.get_config_var('PGO_PROF_USE_FLAG') or 'xxx') in
    (sysconfig.get_config_var('PY_CORE_CFLAGS') or '')):
    raise unittest.SkipTest("test_gdb is not reliable on PGO builds")

If you want to understand why tests are currently skipped when Python is optimized, you should dig into the Git history. Not simply remove the decorator because it looks wrong to you. There is likely a story behind it.

https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence

These python_is_optimized() tests were added in #8605 and #13628. Those issues talk about tests failing when CPython is compiled with -O2 or -O3. But, as I said here, I see no problems today with gcc -O3. So I'm guessing that either gcc or gdb improved such that these tests pass with more recent versions.

There is a fleet of buildbots with a variety og versions of gcc and gdb, so if a change like that is pushed, all the fleet has to be monitored for potential failures, as there are many older OSes supported there.

> Maybe open an issue to attempt to install gdb on Travis CI?

I created PR 14395 for this.

> if a change like that is pushed, all the fleet has to be monitored for potential failures, as there are many older OSes supported there.

If this breaks some buildbots, then we can find out more precisely under which conditions they fail. For example, if they fail when GDB is older than a certain version, we can adjust the tests to check for that version.