- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Growing large images: the case of Moose models

by philippe.back＠highoctane.be

Le 3 mars 2017 13:56, "ClÃ©ment Bera" <bera.clement(a)gmail.com> a Ã©crit : On Fri, Mar 3, 2017 at 12:12 PM, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com > wrote: > On 03/03/2017 11:56, ClÃ©ment Bera wrote: > > Hello everyone, > > > > This morning I investigated with Vincent Blondeau a problem reported by > > the Moose community a while ago: loading Moose model is slower in Spur > > (Pharo 5+) than in pre-Spur (Pharo 4 and older). In general, this > > problem was present for anyone growing images to a significant size. > > > > To investigate the problem, we loaded a 200Mb[3] Moose model on a 250Mb > > image, growing the image to 450Mb. Loading such a model takes 2 minutes > > in Spur and 1m30s in pre-Spur VMs. > > > > Using the stable Pharo VM, the analysis results were the following: > > - total time spent to load the Model: 2 minutes > > - time spent in full GC: 1 minute (4 fullGCs) > > - time spent in scavenges[1]: 15 seconds > > On the 2 minutes spent, we have 50% of the time spent in full GCs, 12.5% > > in scavenges, 37.5% executing code. > > > > We then used the latest VM that features the new compactor (VM from > > beginning of March 2017 and over). The full GC execution time went down > > from 1 minute to 2 seconds. > > > > In addition, we increased the size of Eden[2] from 4Mb to 12Mb. Time > > spent in scavenges decreased from 15 seconds to 5 seconds. > > > > Overall, loading the model is now taking ~50 seconds instead of 2 > minutes. > > > > To increase Eden size, one needs to run a script similar to: > > > > | currentEdenSize desiredEdenSize | > > currentEdenSize := Smalltalk vm parameterAt: 44. > > desiredEdenSize := currentEdenSize * 4. > > Smalltalk vm parameterAt: 45 put: desiredEdenSize. > > > > _*And then restart the image.*_ > > > > I hope this report can be useful for some of you. I will try to make a > > blog post out of it, detailing other GC settings one can change from the > > image to improve performance. > > _* > > *_ > > Best, > > > > Clement > > > > [1] A scavenge is basically the garbage collection of only young objects > > [2] Eden is basically the space where objects are initially allocated. > > [3] All numbers in the report are order of magnitudes and not precise > > numbers > > > > > > > > Hi, > > This is great! We will probably try it soon on our models. > > Guillaume had a question also, what is the counterparty if we let the > EdenSize at this size when we are not loading/exporting a MSE? > There are 2 main counterparts: - You waste a bit of memory. If you increase from 4Mb to 12Mb, you waste 8Mb. - The user-pauses for scavenges may be more significant. There are customers using 64Mb Eden in production. It improves their performance, they do not care about wasting 60Mb on machine with 16Gb RAM and their application does heavy computation and does not need to be that responsive. However for UI applications (typically the IDE), the scavenge pauses may become significant enough to be noticed by the programmer. Maybe not at 12Mb, but certainly at 64Mb. For your case: - Do you care that your application use some more Mb of RAM ? - Do you care if your application takes a couple extra ms to answer a request ? (In any case, the full GC takes much more time and also delays the answer right now) If you don't care, you can use larger Eden. In any case, an Eden of 12 or 16 Mb should be safe. There are other settings that can be useful in your case. I will try to write a post about it. > Because in our case we deploy a server that might need to read some MSE. > We cannot restart it with our current solution. In that case it would be > good to have more info to select the best EdenSize for the server. > > Thank you! > I have images that do not shrink with the new compactor and as there are no leaks I am wondering if there is a way for me to diagnose why this happens. I am routinely loading 100MB XML in the image but these are only transient. Shrinking works with a Pharo6 image but not with a 5.0 based. Strange. Anyone willing to pair over the internet to have a look? It is annoying because I am providing those images to customers and an ever growing thing is not really great especially with a non standard tech I am trying to push forward there. Phil > -- > Cyril Ferlicot > > http://www.synectique.eu > > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France > >

March 3, 2017

Re: [Pharo-dev] Growing large images: the case of Moose models

by ClÃ©ment Bera

On Fri, Mar 3, 2017 at 12:12 PM, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com > wrote: > On 03/03/2017 11:56, ClÃ©ment Bera wrote: > > Hello everyone, > > > > This morning I investigated with Vincent Blondeau a problem reported by > > the Moose community a while ago: loading Moose model is slower in Spur > > (Pharo 5+) than in pre-Spur (Pharo 4 and older). In general, this > > problem was present for anyone growing images to a significant size. > > > > To investigate the problem, we loaded a 200Mb[3] Moose model on a 250Mb > > image, growing the image to 450Mb. Loading such a model takes 2 minutes > > in Spur and 1m30s in pre-Spur VMs. > > > > Using the stable Pharo VM, the analysis results were the following: > > - total time spent to load the Model: 2 minutes > > - time spent in full GC: 1 minute (4 fullGCs) > > - time spent in scavenges[1]: 15 seconds > > On the 2 minutes spent, we have 50% of the time spent in full GCs, 12.5% > > in scavenges, 37.5% executing code. > > > > We then used the latest VM that features the new compactor (VM from > > beginning of March 2017 and over). The full GC execution time went down > > from 1 minute to 2 seconds. > > > > In addition, we increased the size of Eden[2] from 4Mb to 12Mb. Time > > spent in scavenges decreased from 15 seconds to 5 seconds. > > > > Overall, loading the model is now taking ~50 seconds instead of 2 > minutes. > > > > To increase Eden size, one needs to run a script similar to: > > > > | currentEdenSize desiredEdenSize | > > currentEdenSize := Smalltalk vm parameterAt: 44. > > desiredEdenSize := currentEdenSize * 4. > > Smalltalk vm parameterAt: 45 put: desiredEdenSize. > > > > _*And then restart the image.*_ > > > > I hope this report can be useful for some of you. I will try to make a > > blog post out of it, detailing other GC settings one can change from the > > image to improve performance. > > _* > > *_ > > Best, > > > > Clement > > > > [1] A scavenge is basically the garbage collection of only young objects > > [2] Eden is basically the space where objects are initially allocated. > > [3] All numbers in the report are order of magnitudes and not precise > > numbers > > > > > > > > Hi, > > This is great! We will probably try it soon on our models. > > Guillaume had a question also, what is the counterparty if we let the > EdenSize at this size when we are not loading/exporting a MSE? > There are 2 main counterparts: - You waste a bit of memory. If you increase from 4Mb to 12Mb, you waste 8Mb. - The user-pauses for scavenges may be more significant. There are customers using 64Mb Eden in production. It improves their performance, they do not care about wasting 60Mb on machine with 16Gb RAM and their application does heavy computation and does not need to be that responsive. However for UI applications (typically the IDE), the scavenge pauses may become significant enough to be noticed by the programmer. Maybe not at 12Mb, but certainly at 64Mb. For your case: - Do you care that your application use some more Mb of RAM ? - Do you care if your application takes a couple extra ms to answer a request ? (In any case, the full GC takes much more time and also delays the answer right now) If you don't care, you can use larger Eden. In any case, an Eden of 12 or 16 Mb should be safe. There are other settings that can be useful in your case. I will try to write a post about it. > Because in our case we deploy a server that might need to read some MSE. > We cannot restart it with our current solution. In that case it would be > good to have more info to select the best EdenSize for the server. > > Thank you! > > -- > Cyril Ferlicot > > http://www.synectique.eu > > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France > >

March 3, 2017

[pharo-project/pharo-core]

by GitHub

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

March 3, 2017

[pharo-project/pharo-core] 2872a9: 60424

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 2872a98738df4b6ad87eeb0a40feab495032dd3d https://github.com/pharo-project/pharo-core/commit/2872a98738df4b6ad87eeb0a… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-03-03 (Fri, 03 Mar 2017) Changed paths: M Athens-Cairo.package/SQSurfaceDispatch.class/instance/accessing structure variables/getSurfaceFormatFn_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60423.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60424.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60423.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60424.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60424 19787 Athens crashes the VM https://pharo.fogbugz.com/f/cases/19787 http://files.pharo.org/image/60/60424.zip

March 3, 2017

Re: [Pharo-dev] Growing large images: the case of Moose models

by Blondeau Vincent

Thanks Eliot for the implementation of the new compactor! Just to add a piece of information: the mse imported have a size of 40Mb. Cheers, Vincent De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de ClÃ©ment Bera EnvoyÃ© : vendredi 3 mars 2017 11:56 Ã : Discusses Development of Pharo Objet : [Pharo-dev] Growing large images: the case of Moose models Hello everyone, This morning I investigated with Vincent Blondeau a problem reported by the Moose community a while ago: loading Moose model is slower in Spur (Pharo 5+) than in pre-Spur (Pharo 4 and older). In general, this problem was present for anyone growing images to a significant size. To investigate the problem, we loaded a 200Mb[3] Moose model on a 250Mb image, growing the image to 450Mb. Loading such a model takes 2 minutes in Spur and 1m30s in pre-Spur VMs. Using the stable Pharo VM, the analysis results were the following: - total time spent to load the Model: 2 minutes - time spent in full GC: 1 minute (4 fullGCs) - time spent in scavenges[1]: 15 seconds On the 2 minutes spent, we have 50% of the time spent in full GCs, 12.5% in scavenges, 37.5% executing code. We then used the latest VM that features the new compactor (VM from beginning of March 2017 and over). The full GC execution time went down from 1 minute to 2 seconds. In addition, we increased the size of Eden[2] from 4Mb to 12Mb. Time spent in scavenges decreased from 15 seconds to 5 seconds. Overall, loading the model is now taking ~50 seconds instead of 2 minutes. To increase Eden size, one needs to run a script similar to: | currentEdenSize desiredEdenSize | currentEdenSize := Smalltalk vm parameterAt: 44. desiredEdenSize := currentEdenSize * 4. Smalltalk vm parameterAt: 45 put: desiredEdenSize. And then restart the image. I hope this report can be useful for some of you. I will try to make a blog post out of it, detailing other GC settings one can change from the image to improve performance. Best, Clement [1] A scavenge is basically the garbage collection of only young objects [2] Eden is basically the space where objects are initially allocated. [3] All numbers in the report are order of magnitudes and not precise numbers !!!************************************************************************************* "Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.!!!"

March 3, 2017

Re: [Pharo-dev] Growing large images: the case of Moose models

by Cyril Ferlicot D.

On 03/03/2017 11:56, ClÃ©ment Bera wrote: > Hello everyone, > > This morning I investigated with Vincent Blondeau a problem reported by > the Moose community a while ago: loading Moose model is slower in Spur > (Pharo 5+) than in pre-Spur (Pharo 4 and older). In general, this > problem was present for anyone growing images to a significant size. > > To investigate the problem, we loaded a 200Mb[3] Moose model on a 250Mb > image, growing the image to 450Mb. Loading such a model takes 2 minutes > in Spur and 1m30s in pre-Spur VMs. > > Using the stable Pharo VM, the analysis results were the following: > - total time spent to load the Model: 2 minutes > - time spent in full GC: 1 minute (4 fullGCs) > - time spent in scavenges[1]: 15 seconds > On the 2 minutes spent, we have 50% of the time spent in full GCs, 12.5% > in scavenges, 37.5% executing code. > > We then used the latest VM that features the new compactor (VM from > beginning of March 2017 and over). The full GC execution time went down > from 1 minute to 2 seconds. > > In addition, we increased the size of Eden[2] from 4Mb to 12Mb. Time > spent in scavenges decreased from 15 seconds to 5 seconds. > > Overall, loading the model is now taking ~50 seconds instead of 2 minutes. > > To increase Eden size, one needs to run a script similar to: > > | currentEdenSize desiredEdenSize | > currentEdenSize := Smalltalk vm parameterAt: 44. > desiredEdenSize := currentEdenSize * 4. > Smalltalk vm parameterAt: 45 put: desiredEdenSize. > > _*And then restart the image.*_ > > I hope this report can be useful for some of you. I will try to make a > blog post out of it, detailing other GC settings one can change from the > image to improve performance. > _* > *_ > Best, > > Clement > > [1] A scavenge is basically the garbage collection of only young objects > [2] Eden is basically the space where objects are initially allocated. > [3] All numbers in the report are order of magnitudes and not precise > numbers > > > Hi, This is great! We will probably try it soon on our models. Guillaume had a question also, what is the counterparty if we let the EdenSize at this size when we are not loading/exporting a MSE? Because in our case we deploy a server that might need to read some MSE. We cannot restart it with our current solution. In that case it would be good to have more info to select the best EdenSize for the server. Thank you! -- Cyril Ferlicot http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

March 3, 2017

Growing large images: the case of Moose models

by ClÃ©ment Bera

Hello everyone, This morning I investigated with Vincent Blondeau a problem reported by the Moose community a while ago: loading Moose model is slower in Spur (Pharo 5+) than in pre-Spur (Pharo 4 and older). In general, this problem was present for anyone growing images to a significant size. To investigate the problem, we loaded a 200Mb[3] Moose model on a 250Mb image, growing the image to 450Mb. Loading such a model takes 2 minutes in Spur and 1m30s in pre-Spur VMs. Using the stable Pharo VM, the analysis results were the following: - total time spent to load the Model: 2 minutes - time spent in full GC: 1 minute (4 fullGCs) - time spent in scavenges[1]: 15 seconds On the 2 minutes spent, we have 50% of the time spent in full GCs, 12.5% in scavenges, 37.5% executing code. We then used the latest VM that features the new compactor (VM from beginning of March 2017 and over). The full GC execution time went down from 1 minute to 2 seconds. In addition, we increased the size of Eden[2] from 4Mb to 12Mb. Time spent in scavenges decreased from 15 seconds to 5 seconds. Overall, loading the model is now taking ~50 seconds instead of 2 minutes. To increase Eden size, one needs to run a script similar to: | currentEdenSize desiredEdenSize | currentEdenSize := Smalltalk vm parameterAt: 44. desiredEdenSize := currentEdenSize * 4. Smalltalk vm parameterAt: 45 put: desiredEdenSize. *And then restart the image.* I hope this report can be useful for some of you. I will try to make a blog post out of it, detailing other GC settings one can change from the image to improve performance. Best, Clement [1] A scavenge is basically the garbage collection of only young objects [2] Eden is basically the space where objects are initially allocated. [3] All numbers in the report are order of magnitudes and not precise numbers

March 3, 2017

[pharo-project/pharo-core]

by GitHub

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

March 3, 2017

[pharo-project/pharo-core] 6fd1b5: 60423

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 6fd1b56b8c9077b926a43f8078b721843f1da550 https://github.com/pharo-project/pharo-core/commit/6fd1b56b8c9077b926a43f80… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-03-03 (Fri, 03 Mar 2017) Changed paths: M Announcements-Core.package/Announcer.class/README.md M BaselineOfIDE.package/BaselineOfIDE.class/instance/baseline/baseline_.st M BaselineOfIDE.package/BaselineOfIDE.class/instance/baseline/groups_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60422.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60423.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60422.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60423.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A SortFunctions-Core.package/ChainedSortFunction.class/README.md A SortFunctions-Core.package/ChainedSortFunction.class/definition.st A SortFunctions-Core.package/ChainedSortFunction.class/instance/converting/%2C.st A SortFunctions-Core.package/ChainedSortFunction.class/instance/evaluating/value_value_.st A SortFunctions-Core.package/ChainedSortFunction.class/instance/initialize-release/next_.st A SortFunctions-Core.package/SortFunction.class/README.md A SortFunctions-Core.package/SortFunction.class/class/instance creation/ascend.st A SortFunctions-Core.package/SortFunction.class/class/instance creation/descend.st A SortFunctions-Core.package/SortFunction.class/definition.st A SortFunctions-Core.package/SortFunction.class/instance/converting/%2C.st A SortFunctions-Core.package/SortFunction.class/instance/converting/asSortFunction.st A SortFunctions-Core.package/SortFunction.class/instance/converting/toggleDirection.st A SortFunctions-Core.package/SortFunction.class/instance/evaluating/collate_with_.st A SortFunctions-Core.package/SortFunction.class/instance/evaluating/value_value_.st A SortFunctions-Core.package/SortFunction.class/instance/initailize-release/ascend.st A SortFunctions-Core.package/SortFunction.class/instance/initailize-release/collator_.st A SortFunctions-Core.package/SortFunction.class/instance/initailize-release/descend.st A SortFunctions-Core.package/SortFunction.class/instance/initailize-release/direction_.st A SortFunctions-Core.package/SortFunction.class/instance/initailize-release/monadicBlock_.st A SortFunctions-Core.package/SortFunction.class/instance/initailize-release/sendMessage_.st A SortFunctions-Core.package/SortFunction.class/instance/initailize-release/undefinedFirst.st A SortFunctions-Core.package/SortFunction.class/instance/initailize-release/undefinedLast.st A SortFunctions-Core.package/SortFunction.class/instance/testing/hasUndefinedDirection.st A SortFunctions-Core.package/SortFunction.class/instance/testing/isAscending.st A SortFunctions-Core.package/SortFunction.class/instance/testing/isDescending.st A SortFunctions-Core.package/SortFunction.class/instance/testing/isUndefinedFirst.st A SortFunctions-Core.package/SortFunction.class/instance/testing/isUndefinedLast.st A SortFunctions-Core.package/extension/BlockClosure/instance/asSortFunction.st A SortFunctions-Core.package/extension/BlockClosure/instance/ascending.st A SortFunctions-Core.package/extension/BlockClosure/instance/descending.st A SortFunctions-Core.package/extension/Magnitude/instance/threeWayCompareTo_.st A SortFunctions-Core.package/extension/String/instance/threeWayCompareTo_.st A SortFunctions-Core.package/extension/Symbol/instance/asSortFunction.st A SortFunctions-Core.package/extension/Symbol/instance/ascending.st A SortFunctions-Core.package/extension/Symbol/instance/descending.st A SortFunctions-Tests.package/ChainedSortFunctionTest.class/README.md A SortFunctions-Tests.package/ChainedSortFunctionTest.class/definition.st A SortFunctions-Tests.package/ChainedSortFunctionTest.class/instance/tests/testEvaluation.st A SortFunctions-Tests.package/SortFunctionTest.class/README.md A SortFunctions-Tests.package/SortFunctionTest.class/definition.st A SortFunctions-Tests.package/SortFunctionTest.class/instance/tests - sorting/testSorting.st A SortFunctions-Tests.package/SortFunctionTest.class/instance/tests - sorting/testSortingChained.st A SortFunctions-Tests.package/SortFunctionTest.class/instance/tests - sorting/testSortingChainedWithUndefined.st A SortFunctions-Tests.package/SortFunctionTest.class/instance/tests - sorting/testSortingWithUndefined.st A SortFunctions-Tests.package/SortFunctionTest.class/instance/tests/testAsSortFunction.st A SortFunctions-Tests.package/SortFunctionTest.class/instance/tests/testDirectionToggling.st A SortFunctions-Tests.package/SortFunctionTest.class/instance/tests/testSingleArgBlock.st A SortFunctions-Tests.package/SortFunctionTest.class/instance/tests/testTwoArgBlock.st A SortFunctions-Tests.package/SortFunctionTest.class/instance/tests/testUnarySymbol.st A SortFunctions-Tests.package/SortFunctionTest.class/instance/tests/testUndefinedFirstUnary.st A SortFunctions-Tests.package/SortFunctionTest.class/instance/tests/testUndefinedLastUnary.st A SortFunctions-Tests.package/ThreeWayComparisonTest.class/README.md A SortFunctions-Tests.package/ThreeWayComparisonTest.class/definition.st A SortFunctions-Tests.package/ThreeWayComparisonTest.class/instance/tests/testFloats.st A SortFunctions-Tests.package/ThreeWayComparisonTest.class/instance/tests/testIntegers.st A SortFunctions-Tests.package/ThreeWayComparisonTest.class/instance/tests/testStrings.st Log Message: ----------- 60423 19780 Announcer has bad class comment which reference dead link https://pharo.fogbugz.com/f/cases/19780 17728 Integrate Travis Griggs TAG-SortFunctions https://pharo.fogbugz.com/f/cases/17728 http://files.pharo.org/image/60/60423.zip

March 3, 2017

Re: [Pharo-dev] [Moose-dev] Re: Re: Segmentation fault on Moose 6.1 Build

by Pavel Krivanek

The integration took a wrong slice... 2017-03-03 10:34 GMT+01:00 Blondeau Vincent <vincent.blondeau(a)worldline.com> : > Nice try, but it doesn't seems to :( : > https://ci.inria.fr/moose/job/moose-6.1/556/console > > Smalltalk stack dump: > 0xbfc61c50 I GrafPort>copyBits 0x9c1f7a8: a(n) GrafPort > 0xbfc61c70 I GrafPort>image:at:sourceRect:rule: 0x9c1f7a8: a(n) GrafPort > 0xbfc61ca0 I FormCanvas>image:at:sourceRect:rule: 0x9c12a98: a(n) > FormCanvas > > Cheers, > Vincent > > > > -----Message d'origine----- > > De : Moose-dev [mailto:moose-dev-bounces@list.inf.unibe.ch] De la part > de > > Tudor Girba > > EnvoyÃ© : vendredi 3 mars 2017 10:22 > > Ã : Pharo Development List > > Cc : Moose-related development > > Objet : [Moose-dev] Re: [Pharo-dev] Re: Segmentation fault on Moose 6.1 > > Build > > > > Thanks. > > > > I have switched the Moose job back to using the latest image. Letâs see > how > > it works. > > > > Cheers, > > Doru > > > > > > > On Mar 3, 2017, at 9:19 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> > > wrote: > > > > > > Esteban created a working fix for this issue. > > > > > > Cheers, > > > -- Pavel > > > > > > 2017-03-03 3:16 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > > > To confirm specific reproducibility, using... > > > http://files.pharo.org/image/60/60421.zip > > > > > > I did... > > > $ cd opensmalltalk-vm > > > $ git checkout d54edc56 > > > $ git log > > > commit d54edc5638c9f90c80f214e59e19240f8ead87f8 > > > Author: Eliot Miranda <eliot.miranda(a)gmail.com> > > > Date: Thu Mar 2 09:53:05 2017 -0800 > > > CogVM source as per VMMaker.oscog-eem.2143 > > > Fix regression in Sista sources due to receiverTags work. > > > > > > $ cd build.linux32x86/pharo.cog.spur/build.debug > > > $ cd products/debug/phcogspurlinuxht > > > $ pharo ~/temp/Case19785/Pharo-60421.image > > > > > > World > Playground, evaluate... > > > surf := AthensCairoSurface extent: Display extent. > > > Display getCanvas drawImage: surf asForm at: 0@0 > > > > > > 70% ==> image seg fault > > > 30% ==> PrimitiveFailed: primitive #primSignal:andReturnAs: > fromContext: > > > > > > but doing > > > Smalltalk snapshot: true andQuit: true. > > > surf := AthensCairoSurface extent: Display extent. > > > Display getCanvas drawImage: surf asForm at: 0@0. > > > > > > 100% ==> PrimitiveFailed: primitive #primSignal:andReturnAs: > fromContext: > > > > > > > > > Evaluate the following in Playground for 100% segfault from command > line. > > > > > > EllipseMorph compile: 'step > > > |surf| > > > [ surf := AthensCairoSurface extent: Display extent. > > > Display getCanvas drawImage: surf asForm at: 0@0. > > > ] on: Error do: [ ]. > > > self position: self position + (50@0). "To observe survival > of seg > > fault" '. > > > Smalltalk snapshot: true andQuit: true. > > > EllipseMorph new openInWorld. > > > > > > > > > btw, I'm on 32-bit Debian 8 Jessie > > > $ uname -a > > > Linux dom0 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) > > > i686 GNU/Linux > > > > > > cheers -ben > > > > > > > > > On Fri, Mar 3, 2017 at 12:08 AM, Blondeau Vincent > > <vincent.blondeau(a)worldline.com> wrote: > > > > Hi Eliot, > > > > > > > > > > > > > > > > Thanks to take care of this issue! > > > > > > > > > > > > > > > > Pavel opened a bug issue here: > > > > https://pharo.fogbugz.com/f/cases/19785/Athens-crashes-the-VM . You > > > > need the latest Pharo image and VM and it crashes under Linux > > > > (32-bit) and OSX (El Captain, 32-bit VM). And I personally tried > > > > with Windows7 and the bug happens too. > > > > > > > > > > > > > > > > To reproduce: Morph new testAthensRender > > > > > > > > > > > > > > > > An extract of the opened issue: > > > > > > > > > > > > > > > > Edited by Pavel Krivanek 02/03/2017 (Today) 16:10 > > > > > > > > An empty surface crashes it too: > > > > surf := AthensCairoSurface extent: Display extent. > > > > Display getCanvas drawImage: surf asForm at: 0@0 > > > > > > > > > > > > > > > > The problem is in the method AthensCairoSurface>>#asForm where the > > > > previous slice started to add 1 to surface heigth > > > > > > > > > > > > > > > > Well, I tried to revert AthensCairoSurface>>#asForm which fixes this > > > > particular case but Roassal still crashes on copyBits > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Vincent > > > > > > > > > > > > > > > > De : Moose-dev [mailto:moose-dev-bounces@list.inf.unibe.ch] De la > > > > part de Eliot Miranda EnvoyÃ© : jeudi 2 mars 2017 17:03 Ã : Pharo > > > > Development List Cc : Moose-related development; Squeak Virtual > > > > Machine Development Discussion Objet : [Moose-dev] Re: [Pharo-dev] > > > > Segmentation fault on Moose 6.1 Build > > > > > > > > Hi Vincent, > > > > > > > > first, apologies for the inconvenience, second, thanks! I badly > > > > need reproducible failure cases to get the remaining bugs out of the > > > > compactor and you have just provided me with one. Can you send me > > > > the information I need to reproduce the build? What platforms does > it > > fall on? > > > > > > > > On Thu, Mar 2, 2017 at 2:23 AM, Blondeau Vincent > > > > <vincent.blondeau(a)worldline.com> wrote: > > > > > > > > Hi, > > > > > > > > The latest builds of the Moose6.1 image are failing due to a > > > > segmentation fault. > > > > > > > > Here is the link to the last build: > > > > https://ci.inria.fr/moose/job/moose-6.1/550/console > > > > > > > > How can we fix this? > > > > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "Beauty is where we see it." > > > > > > > > > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)list.inf.unibe.ch > > https://www.list.inf.unibe.ch/listinfo/moose-dev > > !!!********************************************************* > **************************** > "Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage > exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret > professionnel. Si vous recevez ce message par erreur, merci d'en avertir > immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne > pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra > Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs > efforts soient faits pour maintenir cette transmission exempte de tout > virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa > responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un > virus transmis. > > This e-mail and the documents attached are confidential and intended > solely for the addressee; it may also be privileged. If you receive this > e-mail in error, please notify the sender immediately and destroy it. As > its integrity cannot be secured on the Internet, the Worldline liability > cannot be triggered for the message content. Although the sender endeavours > to maintain a computer virus-free network, the sender does not warrant that > this transmission is virus-free and will not be liable for any damages > resulting from any virus transmitted.!!!" >

March 3, 2017