tox-dev / tox

Command line driven CI frontend and development task automation tool.
https://tox.wiki
MIT License
3.7k stars 522 forks source link

configuration option disabling sucicide on pytest subprocess #1791

Closed hernot closed 1 year ago

hernot commented 3 years ago

Describe what improvement you want and how would this be used. Thanks! I sometimes need to run pytest under a newer python version eg py38 while my system is running python 3.6 or 3.7 in trace mode

pytest --trace <sometest>::<test_function>

to achieve this i prefer to call it through tox

tox -- --trace <sometest>::<test_function>

In tox.ini i have

[testenv]
comands =
  pytest {posargs}

This basically works as expected but some times the library runs into a endless loop or i want to check if some code executed between two breakpoints is working as expected. This when running pytest directly is achieved by pressing to bail out into pdb debugger. Under tox pytest will be killed after interrupt_timeout is elapsed which is annoying in this case. Therefore i would apriciate if there would be a tox no_suicide or dont_kill or alike option to tell tox to refrain from sending term signal to its subprocesses or at least pytest if specified as parameter for that option and just pass on SIGINT as SIGINT without killing itself..

gaborbernat commented 3 years ago

I have never used the trace flag of pytest, so you'd need to tell more about it. Also what suicide are we talking here about, tox vs pytest?

hernot commented 3 years ago

On Mon, 2021-01-11 at 06:58 +0000, Bernát Gábor wrote:

I have never used the trace flag of pytest, so you'd need to tell more about it. Also what suicide are we talking here about, tox vs pytest?

Tox sends after suicide_timeout the sigint signal to all of its subprocesses. If they do not react to it or do not terminate after termination_timeout it sends according to documentation sig_term to tell the subprocess like pytest to terminate and if it still does not react tox sends finally the sig_kill before terminating it self after all its subprocesses. Which is reasonable in most circumstances.

When you call pytest with --pdb parameter it will start post mortem debugger in case an unhandled exception is thrown while executing a test function and trerminate after. That is a first step to figure which test fails wehere.

When you for in detail investigation call pytest with --trace parameter it will run each test under the regime of python pdb debugger as if one had inserted pdb.set_trace() at the beginning of each test function or called python with -m pdb option activated to run the testcode under the debugger directly. In pytest --trace mode one can set breakpoints, walk up and down the stack and inspect variables visible from within each stack frame as would be possible when running the code directly with python -mpdb testmodule.py Just with the difference that pytest allows to select which test function to put under inspection through the debugger (pdb) in interactive mode. And in this mode pdb will halt the execution of the program/test function at each breakpoint and at what ever point along the execution stack it has received the sigint signal and enters interactive mode allowing user to inspect status of program, variables etc and figure why there is eg. an endless loop etc. Quite helpful to track errors which seem (*) to occur only for newer pyton versions. Under the regime of tox the debugger still switches into interactive mode when receiving sigint but as for tox it looks like as if it did either ignore sigint or hang during termination request and kills it by sigterm and if necessary sigkill, which is not the desired result in this case.

(*) in most cases they just stay unnoticed in the version used to develop the code

gaborbernat commented 1 year ago

This issue was created for 3.x, which is no longer supported, please try with 4.0.

hernot commented 1 year ago

Thanks I'll do and report.