Max,
Thanks for looking into this.
Do you think that this bug will be fixed in Pharo5.0? When I'm debugging
the tests with this fatal pattern, my only recourse is to start and stop
images between test runs ...
The side effect of not running ensure blocks in tests is that a
SharedQueue gets stuck waiting on an empty queue and when I interrupt
that process (and get another debugger that is closed) I end up with the
Empty Debugger problem where the debuggers have decide to stop working
... I saw that there was logic in Process>>terminate involved in dealing
with processes running in critical blocks and that logic might be faulty
as well ...
Dale
On 8/8/16 12:11 AM, Max Leske wrote:
Thanks Nicolai.
I’ve opened an issue on phogbugz:
https://pharo.fogbugz.com/f/cases/18885/Ensure-blocks-in-test-tear-down-not-always-executed.
On 8 Aug 2016, at 09:03, Nicolai Hess <nicolaih...@gmail.com
<mailto:nicolaih...@gmail.com>> wrote:
2016-08-08 8:52 GMT+02:00 Max Leske <maxle...@gmail.com
<mailto:maxle...@gmail.com>>:
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?
Yes, test runs fine in pharo 30864 (halts in the ensure block)
Cheers,
Max
> On 8 Aug 2016, at 03:25, Dale Henrichs
<dale.henri...@gemtalksystems.com
<mailto: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
<http://forum.world.st/Re-Empty-debugger-Pharo-5-0-td4909911.html>
>
> <BugTestCase.st <http://BugTestCase.st>>
