ensure blocks in TestCase>>tearDown are not run if an error occurs inside ensured block when test itself was halted ...
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
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.henrichs@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>
2016-08-08 8:52 GMT+02:00 Max Leske <maxleske@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.henrichs@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>
Thanks Nicolai. Iâve opened an issue on phogbugz: https://pharo.fogbugz.com/f/cases/18885/Ensure-blocks-in-test-tear-down-not-... <https://pharo.fogbugz.com/f/cases/18885/Ensure-blocks-in-test-tear-down-not-...>.
On 8 Aug 2016, at 09:03, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-08-08 8:52 GMT+02:00 Max Leske <maxleske@gmail.com <mailto:maxleske@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.henrichs@gemtalksystems.com <mailto:dale.henrichs@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>
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-....
On 8 Aug 2016, at 09:03, Nicolai Hess <nicolaihess@gmail.com <mailto:nicolaihess@gmail.com>> wrote:
2016-08-08 8:52 GMT+02:00 Max Leske <maxleske@gmail.com <mailto:maxleske@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.henrichs@gemtalksystems.com <mailto:dale.henrichs@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>>
On 8 Aug 2016, at 15:00, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
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 ...
If this is indeed a bug in the termination logic then yes, it will be ported to Pharo 5 since itâs critical.
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 ...
Thanks for the details.
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-... <https://pharo.fogbugz.com/f/cases/18885/Ensure-blocks-in-test-tear-down-not-...>.
On 8 Aug 2016, at 09:03, Nicolai Hess <nicolaihess@gmail.com <mailto:nicolaihess@gmail.com>> wrote:
2016-08-08 8:52 GMT+02:00 Max Leske <maxleske@gmail.com <mailto:maxleske@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.henrichs@gemtalksystems.com <mailto:dale.henrichs@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/>>
2016-08-08 15:26 GMT+02:00 Max Leske <maxleske@gmail.com>:
On 8 Aug 2016, at 15:00, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
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 ...
If this is indeed a bug in the termination logic then yes, it will be ported to Pharo 5 since itâs critical.
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 ...
Thanks for the details.
Hey Max, I looked at Process>>#terminate and I think the problem is that it sets isTerminating := true, but later for the "Unwind error during termination", it spaws a new debugger for this process. And if we now again press "Abondand" we don't try to terminate this process (and don't call the inner ensure-block) because isTerminating is already true.
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 <nicolaihess@gmail.com> wrote:
2016-08-08 8:52 GMT+02:00 Max Leske <maxleske@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.henrichs@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 <http://bugtestcase.st/>>
On 8 Aug 2016, at 17:15, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-08-08 15:26 GMT+02:00 Max Leske <maxleske@gmail.com <mailto:maxleske@gmail.com>>:
On 8 Aug 2016, at 15:00, Dale Henrichs <dale.henrichs@gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> wrote:
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 ...
If this is indeed a bug in the termination logic then yes, it will be ported to Pharo 5 since itâs critical.
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 ...
Thanks for the details.
Hey Max,
I looked at Process>>#terminate and I think the problem is that it sets isTerminating := true, but later for the "Unwind error during termination", it spaws a new debugger for this process. And if we now again press "Abondand" we don't try to terminate this process (and don't call the inner ensure-block) because isTerminating is already true.
Thanks Nicolai, I canât look at the code at the moment, but as far as I recall, sending #terminate twice should signal a warning. So if what youâre saying is true, Iâd expect to see a debugger opened with that warning. I also think that even if there was an unwind error, the process that is already terminating the process within termination should be the only process to continue termination. In other terms: only a single process should ever execute termination for a given process. But thatâs an educated guess, as I donât know how the exception handling is implemented for unwind errors. If itâs indeed how you describe, then I think the proper way to terminate the process in case of an unwind error, would be to pop the contexts up to the next unwind handler and execute that. #terminate should not be sent multiple times. Cheers, Max
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-... <https://pharo.fogbugz.com/f/cases/18885/Ensure-blocks-in-test-tear-down-not-...>.
On 8 Aug 2016, at 09:03, Nicolai Hess <nicolaihess@gmail.com <mailto:nicolaihess@gmail.com>> wrote:
2016-08-08 8:52 GMT+02:00 Max Leske <maxleske@gmail.com <mailto:maxleske@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.henrichs@gemtalksystems.com <mailto:dale.henrichs@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/>>
2016-08-08 17:35 GMT+02:00 Max Leske <maxleske@gmail.com>:
On 8 Aug 2016, at 17:15, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-08-08 15:26 GMT+02:00 Max Leske <maxleske@gmail.com>:
On 8 Aug 2016, at 15:00, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
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 ...
If this is indeed a bug in the termination logic then yes, it will be ported to Pharo 5 since itâs critical.
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 ...
Thanks for the details.
Hey Max,
I looked at Process>>#terminate and I think the problem is that it sets isTerminating := true, but later for the "Unwind error during termination", it spaws a new debugger for this process. And if we now again press "Abondand" we don't try to terminate this process (and don't call the inner ensure-block) because isTerminating is already true.
Thanks Nicolai,
I canât look at the code at the moment, but as far as I recall, sending #terminate twice should signal a warning. So if what youâre saying is true, Iâd expect to see a debugger opened with that warning. I also think that even if there was an unwind error, the process that is already terminating the process within termination should be the only process to continue termination. In other terms: only a single process should ever execute termination for a given process. But thatâs an educated guess, as I donât know how the exception handling is implemented for unwind errors.
If itâs indeed how you describe, then I think the proper way to terminate the process in case of an unwind error, would be to pop the contexts up to the next unwind handler and execute that. #terminate should not be sent multiple times.
There are actually two ensure-blocks involved. If we "Abandon" the first debugger window, the ensure block of TestCase>>#runCase is called, which in turn throws an error from BugTestCase>>#tearDown, so we now have an exception during process terminations unwind operation. That is why the second debugger windonw shows "Unwind error during termination" instead of "Error:teardown". If we new "ABandon" this second debugger window, we try to terminate a process that is within its terminate-and-unwind operation.
Cheers, Max
Dale On 8/8/16 12:11 AM, Max Leske wrote:
Thanks Nicolai.
Iâve opened an issue on phogbugz: https://pharo.fogbug z.com/f/cases/18885/Ensure-blocks-in-test-tear-down-not-always-executed.
On 8 Aug 2016, at 09:03, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-08-08 8:52 GMT+02:00 Max Leske <maxleske@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.henrichs@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 <http://bugtestcase.st/>>
On 9 Aug 2016, at 00:03, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-08-08 17:35 GMT+02:00 Max Leske <maxleske@gmail.com <mailto:maxleske@gmail.com>>:
On 8 Aug 2016, at 17:15, Nicolai Hess <nicolaihess@gmail.com <mailto:nicolaihess@gmail.com>> wrote:
2016-08-08 15:26 GMT+02:00 Max Leske <maxleske@gmail.com <mailto:maxleske@gmail.com>>:
On 8 Aug 2016, at 15:00, Dale Henrichs <dale.henrichs@gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> wrote:
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 ...
If this is indeed a bug in the termination logic then yes, it will be ported to Pharo 5 since itâs critical.
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 ...
Thanks for the details.
Hey Max,
I looked at Process>>#terminate and I think the problem is that it sets isTerminating := true, but later for the "Unwind error during termination", it spaws a new debugger for this process. And if we now again press "Abondand" we don't try to terminate this process (and don't call the inner ensure-block) because isTerminating is already true.
Thanks Nicolai,
I canât look at the code at the moment, but as far as I recall, sending #terminate twice should signal a warning. So if what youâre saying is true, Iâd expect to see a debugger opened with that warning. I also think that even if there was an unwind error, the process that is already terminating the process within termination should be the only process to continue termination. In other terms: only a single process should ever execute termination for a given process. But thatâs an educated guess, as I donât know how the exception handling is implemented for unwind errors.
If itâs indeed how you describe, then I think the proper way to terminate the process in case of an unwind error, would be to pop the contexts up to the next unwind handler and execute that. #terminate should not be sent multiple times.
There are actually two ensure-blocks involved. If we "Abandon" the first debugger window, the ensure block of TestCase>>#runCase is called, which in turn throws an error from BugTestCase>>#tearDown, so we now have an exception during process terminations unwind operation. That is why the second debugger windonw shows "Unwind error during termination" instead of "Error:teardown". If we new "ABandon" this second debugger window, we try to terminate a process that is within its terminate-and-unwind operation.
Ok. Thanks for the analysis.
Cheers, Max
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-... <https://pharo.fogbugz.com/f/cases/18885/Ensure-blocks-in-test-tear-down-not-...>.
On 8 Aug 2016, at 09:03, Nicolai Hess <nicolaihess@gmail.com <mailto:nicolaihess@gmail.com>> wrote:
2016-08-08 8:52 GMT+02:00 Max Leske <maxleske@gmail.com <mailto:maxleske@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.henrichs@gemtalksystems.com <mailto:dale.henrichs@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/>>
Hi dale Le 8/8/16 à 15:00, Dale Henrichs a écrit :
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 ...
Definitively. We do regular backport of fixes when they are important and this one looks important.
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-....
On 8 Aug 2016, at 09:03, Nicolai Hess <nicolaihess@gmail.com <mailto:nicolaihess@gmail.com>> wrote:
2016-08-08 8:52 GMT+02:00 Max Leske <maxleske@gmail.com <mailto:maxleske@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.henrichs@gemtalksystems.com <mailto:dale.henrichs@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>>
Thank you all for taking care and feeling like Pharo is your baby :). Stef Le 8/8/16 à 09:11, Max Leske a écrit :
Thanks Nicolai.
Iâve opened an issue on phogbugz: https://pharo.fogbugz.com/f/cases/18885/Ensure-blocks-in-test-tear-down-not-....
On 8 Aug 2016, at 09:03, Nicolai Hess <nicolaihess@gmail.com <mailto:nicolaihess@gmail.com>> wrote:
2016-08-08 8:52 GMT+02:00 Max Leske <maxleske@gmail.com <mailto:maxleske@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.henrichs@gemtalksystems.com <mailto:dale.henrichs@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>>
participants (4)
-
Dale Henrichs -
Max Leske -
Nicolai Hess -
stepharo