Opened 17 years ago

Closed 5 years ago

#628 defect closed worksforme (worksforme)

Control-C in trial sometimes doesn't stop it.

Reported by: jknight Owned by:
Priority: normal Milestone:
Component: trial Keywords:
Cc: radix, Jean-Paul Calderone, spiv, Jonathan Lange, jknight, slyphon, acapnotic, zooko@… Branch:
Author:

Description


Change History (29)

comment:1 Changed 17 years ago by jknight

Control-C while in trial should interrupt the testing. But, sometimes it just makes the test error 
out and continues testing.

comment:2 Changed 17 years ago by slyphon

try hitting C-\ , it sends SIGQUIT. We have this problem sometimes when running
the unittests for atop.

comment:3 Changed 17 years ago by hypatia

Assigning to slyphon, who seems to be doing the most trial work at the moment

comment:4 Changed 17 years ago by slyphon

yeah, this is a problem with the SIGINT handler, i've yet to figure this out,
but it's on my todo short-list

comment:5 Changed 17 years ago by radix

I haven't noticed this problem in a while. Does the bug still exist?

comment:6 Changed 17 years ago by spiv

It does.  I've added a fix and a test in r13008.

comment:7 Changed 17 years ago by spiv

(Oops, forgot to mark as resolved.)

comment:8 Changed 17 years ago by Jean-Paul Calderone

It'd be nice if ^C went through the normal reporting process instead of
collapsing back into the shell with an ugly traceback.  As it stands, ^C totally
destroys the use of a run.  If it reported the cause of failures in the
truncated run, it could save a lot of time.

comment:9 Changed 17 years ago by spiv

Good idea.  Fixed in r13024.  I'm setting this issue to done-cbb because the
reporting doesn't indicate that ^C happened, but otherwise this seems to work ok.

comment:10 Changed 16 years ago by Jonathan Lange

1. New Maintainer.
2. This hasn't been working for a while.

comment:11 Changed 16 years ago by Jonathan Lange

I think this is working now (as of 14467 in trunk).

comment:12 Changed 16 years ago by Jonathan Lange

Confirmed NOT working.  Regression because apparently it did work.
This bug will not get closed until there are decent tests.

comment:13 Changed 16 years ago by Jonathan Lange

Fixed in r14571.  Still needs more tests.

comment:14 Changed 16 years ago by Jonathan Lange

Lack of tests is a bug

comment:15 Changed 16 years ago by Jonathan Lange

Status: newassigned

In the words of the Bard, Homer, "yours is the butt that will not quit". This issue is an unstoppable undead leper cat ninja.

Please help me write a swag of unit tests to nail it's arse to the floor.

comment:16 Changed 16 years ago by Jonathan Lange

Keywords: waiting added

comment:17 Changed 16 years ago by Jonathan Lange

Adding

signal.signal(signal.SIGINT, lambda *a: result.stop())

to the top of TrialRunner.run makes Ctrl-C interrupt Trial appropriately. Is this the solution? Get Trial to install its own signal handler?

If so, what are the caveats and how do I test it?

comment:18 Changed 15 years ago by Jonathan Lange

Status: assignednew

comment:19 Changed 15 years ago by Jonathan Lange

Priority: highnormal

comment:20 Changed 14 years ago by Jean-Paul Calderone

Keywords: waiting removed

Yep, that's right.

Testing isn't hard. Make a test that catches KeyboardInterrupt and ignores it, then make sure it can be interrupted with SIGINT.

comment:21 Changed 14 years ago by acapnotic

Cc: acapnotic added

comment:22 Changed 12 years ago by Jean-Paul Calderone

#3975 was a duplicate of this.

comment:23 Changed 11 years ago by zooko

Mike Malone and I were orking cows together and he was frustrated by this ticket. It was my idea to use features of trial which require him to run trial instead of pyunit so now I feel motivated to improve this behavior of trial.

comment:24 Changed 11 years ago by zooko

Cc: zooko@… added

Mike Malone and I were orking cows together and he was frustrated by this ticket. It was my idea to use features of trial which require him to run trial instead of pyunit so now I feel motivated to improve this behavior of trial.

comment:25 Changed 11 years ago by Mike Malone

More specifically, this seems _really_ broken when you use the twisted.trial.unittest module but run your tests through the standard python setup.py test mechanism. In that case C-c just kills the current test and moves along to the next one (at least for me). Super annoying if you have hundreds of tests and want to exit early.

When I ran tests using the trial command I was seeing some weird behavior where I had to C-c twice to kill the tests. But at least I could kill them.

Sorry for the lack of detail. Will try to create a small test case that repros it. I don't have a very deep knowledge of the twisted/trial internals though. Blerg.

comment:26 Changed 11 years ago by Jean-Paul Calderone

Apparently this issue has been fixed many times in Twisted's history!

Perhaps it would be useful to clarify exactly what should happen when a user hits C-c mid-run.

Some things to consider:

  • Python wants C-c to mean raise KeyboardInterrupt()
  • Reactors want C-c to mean reactor.stop()

If trial wants it to mean something else, these two expectations will have to be violated. This isn't necessarily a problem, but:

  • What if a test is running a while True: loop with a KeyboardInterrupt handler around it, expecting to be able to return from the test method when KeyboardInterrupt is handled?
  • (Basically the same question, but) What if a test method is running a reactor and expecting it to stop before returning?

Merely stopping the test results object won't cause either of these test methods to complete. However, are they realistic cases? Would you want to do these things not-by-accident?

Also I re-iterate what I said above about partial result reporting, since that's no longer the behavior.

Also hopefully the case for using trial as a runner and the case for using some other unittest runner are actually the same case, and if we fix this for the general unittest runner case it will just work with trial. Or perhaps that's wishful thinking.

comment:27 Changed 11 years ago by therve

FWIW, #3888 may or may not be the behavior you see when you use the stdlib runner.

comment:28 Changed 11 years ago by <automation>

Owner: Jonathan Lange deleted

comment:29 Changed 5 years ago by Glyph

Resolution: worksforme
Status: newclosed

There are certainly still cases where C-c might not interrupt a test run, but, it seems to do what I expect except in the cases where the tests have done something horrible to the terminal or to their own signal handlers. If someone can articulate a specific reason why tests are hung that is a result of trial's behavior, they should file a new bug, probably.

Note: See TracTickets for help on using tickets.