While attempting to characterize the "Empty Debugger" problem that I've recently reported[1], I found that ensure blocks in TestCase>>teardown methods are not run if an Error is signaled while executing the code protected by the ensure block ... when the test itself brings up a debugger --- now that is a mouthful :) ... but a situation that commonly occurs ... I've attached a fileIn with a very simple reproduction of this problem. After filing in the code, execute the following: BugTestCase debug: #test. Abandon the first halt -- this is the halt in the test. Next a debugger is brought up on the error from inside the ensure block in the tearDown method: tearDown [ self error: 'teardown' ] ensure: [ "Imagine that something important NEEDED to be done here" self halt ]. super tearDown. Abandon the error and the `self halt` in the ensure block is not run ... If you take the `self halt` out of the test method itself, the `self halt` in the ensure block _is_ run ... This does not directly lead to the Empty Debugger, but when the ensure blocks called during teardown are not run, a resource is not cleaned up properly and that leads to SharedQueue hanging ... when I interrupt the SharedQueue, I believe that this leads to the "Empty Debugger" a separate, but more nasty problem ... Dale [1] http://forum.world.st/Re-Empty-debugger-Pharo-5-0-td4909911.html