classification
Title: test_gdb disables 25% of tests in optimized builds
Type: Stage: resolved
Components: Tests Versions: Python 3.7, Python 3.6
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: benjamin.peterson, dmalcolm, lukasz.langa, pitrou, vstinner
Priority: normal Keywords:

Created on 2017-08-18 23:39 by lukasz.langa, last changed 2017-08-25 16:33 by lukasz.langa. This issue is now closed.

Messages (6)
msg300554 - (view) Author: Łukasz Langa (lukasz.langa) * (Python committer) Date: 2017-08-18 23:39
We are skipping a lot of tests when optimizations are enabled (which essentially means: compiled without `--with-pydebug`). This seems overly aggressive since most Python users are using the gdb bindings with a non-debug build.

I think we should have tests for py-bt, py-up, printing globals, etc. that run on a non-debug build.
msg300555 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-08-18 23:47
Sadly, python-gdb fails to get required data for some commands, so python-gdb doesn't work fully on optimized builds.
msg300649 - (view) Author: Łukasz Langa (lukasz.langa) * (Python committer) Date: 2017-08-21 20:08
You're being vague, can you say which optimized builds and which data? As I mentioned, builds that actual users use are almost always compiled without --with-pydebug. That includes, say, the default RedHat python RPMs or the Debian DEBs that ship with those operating systems.

It's not enough for us to run those tests only for --with-pydebug, as shown by bpo-30983, which wasn't discovered sooner because it only affects shared non-debug builds.
msg300650 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2017-08-21 20:17
I don't think it's a surprise that reconstructing high-level program information from a debugger works less well on optimized builds.  Perhaps Dave Malcolm has more precise information about what is supposed to to work and what is not.
msg300653 - (view) Author: Dave Malcolm (dmalcolm) (Python committer) Date: 2017-08-21 21:38
The problem is that there are so many variables:
* which version of which compiler
* optimization flags
* which version of gdb
* which CPU architecture
etc (and the compiler and/or gdb could be carrying patches from downstream distributors...)

All of these can affect the debugging experience; as soon as optimizations are turned on it's very hard to predict exactly how well we can capture the frame information in the debugger.

Hence it makes sense to skip these tests for optimized builds, to avoid creating noise in the buildbots.

Downstream distributions might want to re-enable the tests, if they have sufficient control over the compiler and debugger versions that are in use, I guess.

Or maybe there's a way to express some of the above sanely?  Not sure.

Hope this is constructive.
msg300847 - (view) Author: Łukasz Langa (lukasz.langa) * (Python committer) Date: 2017-08-25 16:33
I guess it's wontfix then. Sad, since that leaves us partially blind to regressions like bpo-30983.
History
Date User Action Args
2017-08-25 16:33:33lukasz.langasetstatus: open -> closed
resolution: wont fix
stage: resolved
2017-08-25 16:33:22lukasz.langasetmessages: + msg300847
2017-08-21 21:38:57dmalcolmsetmessages: + msg300653
2017-08-21 20:17:52pitrousetnosy: + dmalcolm
messages: + msg300650
2017-08-21 20:08:50lukasz.langasetmessages: + msg300649
2017-08-18 23:47:12vstinnersetmessages: + msg300555
2017-08-18 23:39:31lukasz.langacreate