no way to drop into a debugger safely

Bug #902881 reported by Robert Collins on 2011-12-11
54
This bug affects 11 people
Affects Status Importance Assigned to Milestone
Testrepository
Wishlist
Unassigned

Bug Description

subunit was intended to support dropping into a debugger in a run. v1 was line based, v2 is debugger ready.

However, some things like parallel tests are intrinsically incompatible with naively just glueing stdin and stdout together.

There are a few ways this could be done at a UX level, and then a few implementation level.

Firstly, the building blocks we have to work with:
 - subunit.run, the Python subunit runner could change the meaning of pdb.set_trace() so that some special subunit information was sent (and ditto on exiting of pdb). Presumably similar mechanisms could be written for other debuggers. Looking at the existing art for debugger glue in IDEs would be a good thing to do.
 - testr doesn't let tests write to its stdout at the moment, so the UI is entirely available for us to use if we want to. Making readline etc work might be non-trivial, but that could always be improved on.
 - we have full bidirectional routing available through the network of subunit routers - we can send tagged packets to processes, and receive them on arbitrary fd's.
 - we have the full Python ecosystem of libraries available for the testr UI itself

Possible user experiences:
 - testr run --debug : don't parallelise, and attach stdout, err and in to their equivalents on the test process (ignoring routing and packetisation etc), so that line based debuggers Just Work (assuming their IO redirection works)
 - testr run --debug but also move the subunit stream out of stdout, use a pipe or something, and then we can capture IO at the actual IO layer, not via in-process shims.
 - testr run --debug could not parallelise *and* switch to a different runner, allowing you to just be talking directly to it on stdin/out/err. Would require configuration changes.
 - testr run as normal, and if testr detects a debugger somehow, it throws that into the main UI, blocking out any other debuggers from other backends. May go down a pit of despair in that we need to emulate terminals, but could be very nice.
 - testr run as normal, but glue stdout/err and in from each backend into a temp socket in /tmp somewhere. Then if a process is in the debugger, the user can connect to it via screen /tmp/testr.123123/backend-45 and talk directly (again ignoring encapsulation) as needed. We'd want to detect pipe full and start discarding all but the latest stuff (e.g. in a ring buffer) to make users doing this an optional thing. We could perhaps show slow tests (backend 34 has not sent a packet in 2 minutes) to point users at the right place.

Jonathan Lange (jml) wrote :

Sort of related to bug 606769.

description: updated
description: updated
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers