- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60173 Home: https://github.com/pharo-project/pharo-core

Aug. 8, 2016

[pharo-project/pharo-core] 4f6532: 60173

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 4f65322e02872435ab25321bfe399c0c5fd166ba https://github.com/pharo-project/pharo-core/commit/4f65322e02872435ab25321b… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-08-08 (Mon, 08 Aug 2016) Changed paths: M ConfigurationOfFlatQA.package/ConfigurationOfFlatQA.class/instance/symbolic versions/stable_.st A ConfigurationOfFlatQA.package/ConfigurationOfFlatQA.class/instance/versions/versionv3%5F2%5F4_.st M Renraku.package/ReAbstractRule.class/instance/helpers/critiqueFor_.st A Renraku.package/ReInvocationSequenceRule.class/class/as yet unclassified/isVisible.st M Renraku.package/extension/RBLintRule/instance/critiqueFor_.st M Renraku.package/extension/RBParseTreeLintRule/instance/critiqueFor_about_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60172.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60173.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60172.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60173.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60173 18887 QA 3.2.4 https://pharo.fogbugz.com/f/cases/18887 http://files.pharo.org/image/60/60173.zip

Aug. 8, 2016

Re: [Pharo-dev] Problem with delay waiting (OSSubprocess code) on Pharo 5.0

by Mariano Martinez Peck

Hi Ben, Sorry, I do not have yet a verdict. The part of the system that reproduces the crash is not used frequently so it takes me quite some time to reproduce it :( Will keep you informed if I see it again or not with the last changes. Thanks for checking with me. On Mon, Aug 8, 2016 at 12:43 PM, Ben Coman <btc(a)openinworld.com> wrote: > Hi Mariano, How are you going with this problem? > > On Fri, Jul 22, 2016 at 11:05 PM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: > > > > > > On Fri, Jul 22, 2016 at 2:26 AM, Ben Coman <btc(a)openinworld.com> wrote: > >> > >> > >> > >> On Fri, Jul 22, 2016 at 4:42 AM, Mariano Martinez Peck > >> <marianopeck(a)gmail.com> wrote: > >>> > >>> > >>> > >>> On Sun, Jul 17, 2016 at 6:46 AM, Ben Coman <btc(a)openinworld.com> > wrote: > >>> > >>>> > >>>> Do you have some test code or a test image I could run to reproduce > >>>> the problem? > >>> > >>> > >>> > >>> The problem is that I cannot reproduce it immediately. It takes me some > >>> days and likely some image save and start again until I reproduce it. > >> > >> > >> Could you try > >> How about something that invokes > >> > > > > > > Hi Ben. I tried to reproduce it in a couple of ways, trying to simulate > what > > I do for real but I failed: > > > > | commandString | > > commandString := 'wkhtmltopdf --javascript-delay 300 --encoding utf8 > > --page-size A4 --image-quality 100 --footer-spacing 10 > --header-spacing 10 > > --margin-top 10 --header-html "http://google.com" --footer-html > > "http://google.com" "http://pharo.org/" "/tmp/TestPharoExport.pdf"'. > > > > 10 timesRepeat: [ > > > > 3 timesRepeat: [ > > OSSUnixSubprocess new > > shellCommand: commandString; > > redirectStdout; > > redirectStderr; > > runAndWaitOnExitDo: [ :command :outString :errString | > > Transcript show: errString. > > Transcript show: outString. > > ]. > > ]. > > Smalltalk saveSession. > > > > ] > > > > But...I could not yet reproduce it in the real case either....so I will > keep > > you informed. > > > > > >>> > >>> > >>>> > >>>> > >>>> Now I have one thing for you to try. In the move of DelaySchedulerXxx > >>>> from milliseconds to microseconds, the code for dealing with clock > >>>> wrap-around was removed, but I wonder if it was also covering clock > >>>> jitter as a side effect. Could you try again the SpinScheduler but > >>>> restore this code... > >>>> > >>>> From handletTimerEvent... > >>>> "Check for clock wrap-around." > >>>> millisecondNowTick < activeDelayStartTime ifTrue: [ > >>>> "clock wrapped" > >>>> self saveResumptionTimes. > >>>> self restoreResumptionTimes ]. > >>>> activeDelayStartTime := millisecondNowTick. > >>>> > >>>> From runTimerEventLoop... > >>>> Time millisecondClockValue < millisecondNowTick > >>>> ifTrue:[ timingSemaphore signal ]. "retry" > >>>> > >>>> From startup... > >>>> activeDelayStartTime := Time millisecondClockValue. > >>>> > >>> > >>> OK, I put back the code into the spin scheduler. Then I kept using > >>> milisecond one until I finished the changes. Then I saved image and > switch > >>> to spin one: the image hungs. I cannot even interrupt it. I attach my > >>> modifications. > >>> Do they look correct? > >> > >> > >> I confirm that locked my image also. > >> > >> One change of milli to micro was missed at the bottom of > >> runTimeEventLoop... > >> That is... > >> Time millisecondClockValue < microsecondNowTick > >> to... > >> Time microsecondClockValue < microsecondNowTick > >> > > Thanks. That did the trick! > > -- Mariano http://marianopeck.wordpress.com

Aug. 8, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60172 Home: https://github.com/pharo-project/pharo-core

Aug. 8, 2016

[pharo-project/pharo-core] 922d2d: 60172

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 922d2dc6370262484a8c725129e2ae39b5cb2d0c https://github.com/pharo-project/pharo-core/commit/922d2dc6370262484a8c7251… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-08-08 (Mon, 08 Aug 2016) Changed paths: M AST-Core.package/RBParser.class/instance/private-parsing/parseBlock.st A AST-Tests-Core.package/RBParserTest.class/instance/private/parseFaultyExpression_.st A AST-Tests-Core.package/RBParserTest.class/instance/tests parsing/testParseUnfinishedBlockWithFaultyBody.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60171.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60172.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60171.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60172.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Shout.package/SHRBTextStyler.class/instance/private/styleCloseBracket_.st M Shout.package/SHRBTextStyler.class/instance/private/styleOpenBracket_.st M Tool-CriticBrowser.package/SingleCodeCriticResultList.class/instance/initialization/setTextModelForClassOrMethod_.st M Tool-CriticBrowser.package/SingleCodeCriticResultList.class/instance/initialization/setTextModelForNil.st M Tool-CriticBrowser.package/SingleCodeCriticResultList.class/instance/initialization/whenSelectedItemChangesOnListModel.st M Tool-CriticBrowser.package/SingleCodeCriticResultList.class/instance/menu/addNavigationMenuItemsTo_.st M Tool-CriticBrowser.package/SingleCodeCriticResultList.class/instance/menu/menu_shifted_.st M Tool-SystemReporter.package/SystemReporter.class/instance/reporting/reportWorkingCopies_.st Log Message: ----------- 60172 18878 MNU ReINvocationSequenceRule isArchitecturalRule https://pharo.fogbugz.com/f/cases/18878 18886 parsing an unfinished block with invalid expressions in its body should not create only a single parse error node https://pharo.fogbugz.com/f/cases/18886 18883 SystemReporter calls deprecated #name on MCWorkingCopy https://pharo.fogbugz.com/f/cases/18883 http://files.pharo.org/image/60/60172.zip

Aug. 8, 2016

Re: [Pharo-dev] Problem with delay waiting (OSSubprocess code) on Pharo 5.0

by Ben Coman

Hi Mariano, How are you going with this problem? On Fri, Jul 22, 2016 at 11:05 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Fri, Jul 22, 2016 at 2:26 AM, Ben Coman <btc(a)openinworld.com> wrote: >> >> >> >> On Fri, Jul 22, 2016 at 4:42 AM, Mariano Martinez Peck >> <marianopeck(a)gmail.com> wrote: >>> >>> >>> >>> On Sun, Jul 17, 2016 at 6:46 AM, Ben Coman <btc(a)openinworld.com> wrote: >>> >>>> >>>> Do you have some test code or a test image I could run to reproduce >>>> the problem? >>> >>> >>> >>> The problem is that I cannot reproduce it immediately. It takes me some >>> days and likely some image save and start again until I reproduce it. >> >> >> Could you try >> How about something that invokes >> > > > Hi Ben. I tried to reproduce it in a couple of ways, trying to simulate what > I do for real but I failed: > > | commandString | > commandString := 'wkhtmltopdf --javascript-delay 300 --encoding utf8 > --page-size A4 --image-quality 100 --footer-spacing 10 --header-spacing 10 > --margin-top 10 --header-html "http://google.com" --footer-html > "http://google.com" "http://pharo.org/" "/tmp/TestPharoExport.pdf"'. > > 10 timesRepeat: [ > > 3 timesRepeat: [ > OSSUnixSubprocess new > shellCommand: commandString; > redirectStdout; > redirectStderr; > runAndWaitOnExitDo: [ :command :outString :errString | > Transcript show: errString. > Transcript show: outString. > ]. > ]. > Smalltalk saveSession. > > ] > > But...I could not yet reproduce it in the real case either....so I will keep > you informed. > > >>> >>> >>>> >>>> >>>> Now I have one thing for you to try. In the move of DelaySchedulerXxx >>>> from milliseconds to microseconds, the code for dealing with clock >>>> wrap-around was removed, but I wonder if it was also covering clock >>>> jitter as a side effect. Could you try again the SpinScheduler but >>>> restore this code... >>>> >>>> From handletTimerEvent... >>>> "Check for clock wrap-around." >>>> millisecondNowTick < activeDelayStartTime ifTrue: [ >>>> "clock wrapped" >>>> self saveResumptionTimes. >>>> self restoreResumptionTimes ]. >>>> activeDelayStartTime := millisecondNowTick. >>>> >>>> From runTimerEventLoop... >>>> Time millisecondClockValue < millisecondNowTick >>>> ifTrue:[ timingSemaphore signal ]. "retry" >>>> >>>> From startup... >>>> activeDelayStartTime := Time millisecondClockValue. >>>> >>> >>> OK, I put back the code into the spin scheduler. Then I kept using >>> milisecond one until I finished the changes. Then I saved image and switch >>> to spin one: the image hungs. I cannot even interrupt it. I attach my >>> modifications. >>> Do they look correct? >> >> >> I confirm that locked my image also. >> >> One change of milli to micro was missed at the bottom of >> runTimeEventLoop... >> That is... >> Time millisecondClockValue < microsecondNowTick >> to... >> Time microsecondClockValue < microsecondNowTick >> > Thanks. That did the trick!

Aug. 8, 2016

Re: [Pharo-dev] ensure blocks in TestCase>>tearDown are not run if an error occurs inside ensured block when test itself was halted ...

by Max Leske

> On 8 Aug 2016, at 17:15, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-08-08 15:26 GMT+02:00 Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>>: > >> On 8 Aug 2016, at 15:00, Dale Henrichs <dale.henrichs(a)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(a)gmail.com <mailto:nicolaihess@gmail.com>> wrote: >>>> >>>> >>>> >>>> 2016-08-08 8:52 GMT+02:00 Max Leske <maxleske(a)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(a)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/>>

Aug. 8, 2016

Re: [Pharo-dev] ensure blocks in TestCase>>tearDown are not run if an error occurs inside ensured block when test itself was halted ...

by Nicolai Hess

2016-08-08 15:26 GMT+02:00 Max Leske <maxleske(a)gmail.com>: > > On 8 Aug 2016, at 15:00, Dale Henrichs <dale.henrichs(a)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(a)gmail.com> wrote: > > > > 2016-08-08 8:52 GMT+02:00 Max Leske <maxleske(a)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/>> >> >> >> > > > >

Aug. 8, 2016

using glorp and active record

by Sean Glazier

Hi, I have been trying to get glorp using active record working in pharo 5. I have a descriptor class for it and the classes inherit from active Record. I describe the table as: tableForAnswer: aTable | vistorId questionId | (aTable createFieldNamed: 'id' type: platform serial) bePrimaryKey. questionId := aTable createFieldNamed: 'questionId' type: platform integer. vistorId := aTable createFieldNamed: 'vistorId' type: platform integer. aTable createFieldNamed: 'answer' type: platform text. aTable addForeignKeyFrom: vistorId to: ((self tableNamed: 'VISITORS') fieldNamed: 'ID') suffixExpression: 'MATCH SIMPLE ON UPDATE NO ACTION ON DELETE CASCADE'. aTable addForeignKeyFrom: questionId to: ((self tableNamed: 'QUESTIONS') fieldNamed: 'ID') suffixExpression: 'MATCH SIMPLE ON UPDATE NO ACTION ON DELETE CASCADE' the table in the DB was preexisting. when I do Answer findAll I get and error that it is expecting a number for the id field. in the PostgresSQLPlaform serial is defined thusly. serial "For postgresql, we use sequences, and explicitly get the values ourselves, so just tell the database that they're integers." ^self typeNamed: #serial ifAbsentPut: [GlorpSerialType new typeString: 'integer']. What the DB hands back is 'nextval('answers_id_seq'::regclass)' which seems correct if it is telling me that there exists a sequence for this field and that is the correct command to issue for the field. am I defining this table incorrectly? or should I bag using active Record. I kind of liked it when working in Visualworks because there were also tools that would read in and describe the tables and then tools to assit when you needed to migrate to another version and do the changes etc. FYI this is the query that is being run that fails. SELECT t1.table_name, t1.table_schema, t1.column_name, t1.is_nullable, t1.data_type, t1.column_default, t1.character_maximum_length, EXISTS (SELECT DISTINCT 'x' FROM ((INFORMATION_SCHEMA.table_constraints s1t1 INNER JOIN INFORMATION_SCHEMA.key_column_usage s1t3 ON ((s1t1.table_name = s1t3.table_name) AND ((s1t1.table_schema = s1t3.table_schema) AND (s1t1.constraint_name = s1t3.constraint_name)))) INNER JOIN INFORMATION_SCHEMA.columns s1t2 ON (((s1t3.column_name = s1t2.column_name) AND (s1t3.table_schema = s1t2.table_schema)) AND (s1t3.table_name = s1t2.table_name))) WHERE ((s1t1.constraint_type = 'PRIMARY KEY') AND ((s1t2.column_name = t1.column_name) AND (((s1t2.table_schema = t1.table_schema) AND (s1t2.table_name = t1.table_name)) AND ((s1t2.table_schema = t1.table_schema) AND (s1t2.table_name = t1.table_name)))))) FROM INFORMATION_SCHEMA.columns t1 WHERE ((t1.table_name = 'answers') AND (t1.table_schema = 'public')) it looks as though it is reading in the schema and is expecting and integer because we told it to in the serial method on the PostgesSQLPlatform. As much as I love diving into these frameworks to figure out the deep inner workings, I really need to be getting data in and out without a fuss. Should I follow the DBX example where the descriptor is orthogonal to the model and one does not subclass from active record? I also note that not all the glorp tests pass. I think the were rather minor fails like timezone issues or something. It took a while but the test created a number of tables in the DB. So again Have I done something Obtuse that I qught to be slapped for here? thanks

Aug. 8, 2016

Re: [Pharo-dev] ensure blocks in TestCase>>tearDown are not run if an error occurs inside ensured block when test itself was halted ...

by Max Leske

> On 8 Aug 2016, at 15:00, Dale Henrichs <dale.henrichs(a)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(a)gmail.com <mailto:nicolaihess@gmail.com>> wrote: >>> >>> >>> >>> 2016-08-08 8:52 GMT+02:00 Max Leske <maxleske(a)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(a)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/>> >>> >>> >>> >> >

Aug. 8, 2016