Wow, that’s pretty bad. The process termination logic should be taking care of the ensure blocks. Unfortunately I can’t run any Pharo images at the moment but if there’s something wrong with process termination then it’s likely that me or Ben made some mistake. Could someone please rerun Dale’s test scenario with the original process termination code (e.g. from Pharo 3) and report the results?
Cheers, Max > On 8 Aug 2016, at 03:25, Dale Henrichs <dale.henri...@gemtalksystems.com> > wrote: > > 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 > > <BugTestCase.st>
