- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] ReÂ : Re: Metacello load script won't update the configuration

by Christophe Demarey

Le 23 nov. 2015 Ã 20:32, Marcus Denker a Ã©crit : > >> On 23 Nov 2015, at 16:25, Christophe Demarey <christophe.demarey(a)inria.fr> wrote: >> >> I did the configuration 2 months ago but was not integrated because of some critics rules failing. And some of them are not valid for a project supporting many smalltalk and many versions. >> I synchronized all the code and tests were green. >> The code is not worst as the current metacello version so I do not see why it is not integrated. >> > > because with >650 issues I do never look through all of them because an issue âWork neededâ might be ready for integration. > I *only* look at issues that are âfix review neededâ or âfix reviewed by the monkeyâ. That is easily understandable. What I meant is that StÃ©phane tried to integrate it (I told StÃ©phane that it was ready) but the integration failed and I did not get the reason back. I will try to resync (again) and provide critics feedback to Dale.

Nov. 24, 2015

Re: [Pharo-dev] Rules

by Yuriy Tymchuk

Essentially there should be 3 things: 1) clear name like: 'super' should receiver the same message (or similar). 2) good rationale explaining that you have to send the message to self and then either override it or let it run from supper, as this allows better flexibility. 3) make an automate fixing (as it is trivial). It should be doable by rewrite rules I suppose, but what annoys me is that when you use them, you donât have the matched string, nor the interval, so you cannot highlight itâ¦ Anyway, it is on my todolist. Cheers. Uko > On 24 Nov 2015, at 09:32, Nicolas Anquetil <Nicolas.Anquetil(a)inria.fr> wrote: > > > > On 23/11/2015 22:14, stepharo wrote: >> >> >> Le 22/11/15 22:11, Yuriy Tymchuk a Ã©crit : >>> Hi. >>> >>> The rule is correct. Sending a different message to super may be confusing. In this case you are in âprintOn:â method and you are sending âprintOn:nextPutAll:â to super. The idea is that you have to send âprintOn:nextPutAll:â to self and then either it will invoke the super one, you there will be an overridden method in your current class. >> >> exactly but do you expect a newbie to understand anything with the current explanation? >> I do not. >> >> " >> >> Rewrite super messages to self messages when both refer to same method" > What about : > "'super' should call the same selector. Send different selector to 'self' then use 'super' in this one." > ? > > or: > > "should not send a different message to super (send different message to self and then call super from it)" > ? > > > > nicolas >> >> Sucks >> >>> >>> Secondly, there is an issue with âsends unkown selectorâ. Iâve also noticed it recently. I think that it happens because the rule has a special cace, and I messed up something with refresh. This is the next thing on my TODO list. >>> >>> Cheers. >>> Uko >>> >>> >>>> On 22 Nov 2015, at 16:33, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>>> >>>> >>>>> On 22 Nov 2015, at 12:20, stepharo <stepharo(a)free.fr> wrote: >>>>> >>>>> With the following (broken) definition >>>>> >>>>> >>>>> : aStream >>>>> super printOn: aStream >>>>> aStream nextPutAll: '(', faces printString , ')' >>>>> >>>>> I got this strange rule: >>>>> >>>>> Rewrite super messages to self messages when both refer to same method >>>>> >>>>> I do not get it and it looks really suspicious to me. >>>>> Any suggestions? >>>> The rule is meant to catch the case when when âsuperâ can be âselfâ as there is no #printOn: >>>> defined in the class. >>>> >>>> But here it looks like it is wrong: it would be an infinite loop. >>>> >>>> I think it could be related to this other bug: I have seen that the rules are not correctly updated >>>> when you add methods. (I wanted to add an issue for that but did not yet). E.g. I often get >>>> a âsends unkown selectorâ for self sends and then I check â> method is there, I just added it! >>>> >>>> So here this means that you added a new printOn:, the rules do not update, and it thinks >>>> that there is no printOn:. >>>> >>>> So the real bug is that added methods need to be taken into account by QA. >>>> >>>> Marcus >>> >>> >> >> > > -- > Nicolas Anquetil > RMod team -- Inria Lille

Nov. 24, 2015

Re: [Pharo-dev] Rules

by Nicolas Anquetil

On 23/11/2015 22:14, stepharo wrote: > > > Le 22/11/15 22:11, Yuriy Tymchuk a Ã©crit : >> Hi. >> >> The rule is correct. Sending a different message to super may be >> confusing. In this case you are in âprintOn:â method and you are >> sending âprintOn:nextPutAll:â to super. The idea is that you have to >> send âprintOn:nextPutAll:â to self and then either it will invoke the >> super one, you there will be an overridden method in your current class. > > exactly but do you expect a newbie to understand anything with the > current explanation? > I do not. > > " > > Rewrite super messages to self messages when both refer to same method" What about : "'super' should call the same selector. Send different selector to 'self' then use 'super' in this one." ? or: "should not send a different message to super (send different message to self and then call super from it)" ? nicolas > > Sucks > >> >> Secondly, there is an issue with âsends unkown selectorâ. Iâve also >> noticed it recently. I think that it happens because the rule has a >> special cace, and I messed up something with refresh. This is the >> next thing on my TODO list. >> >> Cheers. >> Uko >> >> >>> On 22 Nov 2015, at 16:33, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> >>>> On 22 Nov 2015, at 12:20, stepharo <stepharo(a)free.fr> wrote: >>>> >>>> With the following (broken) definition >>>> >>>> >>>> : aStream >>>> super printOn: aStream >>>> aStream nextPutAll: '(', faces printString , ')' >>>> >>>> I got this strange rule: >>>> >>>> Rewrite super messages to self messages when both refer to same >>>> method >>>> >>>> I do not get it and it looks really suspicious to me. >>>> Any suggestions? >>> The rule is meant to catch the case when when âsuperâ can be âselfâ >>> as there is no #printOn: >>> defined in the class. >>> >>> But here it looks like it is wrong: it would be an infinite loop. >>> >>> I think it could be related to this other bug: I have seen that the >>> rules are not correctly updated >>> when you add methods. (I wanted to add an issue for that but did not >>> yet). E.g. I often get >>> a âsends unkown selectorâ for self sends and then I check â> method >>> is there, I just added it! >>> >>> So here this means that you added a new printOn:, the rules do not >>> update, and it thinks >>> that there is no printOn:. >>> >>> So the real bug is that added methods need to be taken into account >>> by QA. >>> >>> Marcus >> >> > > -- Nicolas Anquetil RMod team -- Inria Lille

Nov. 24, 2015

Re: [Pharo-dev] Basic versioning of GitHub repositories from within Pharo

by Dimitris Chloupis

I suggest all interested parties to > > - review the code of skip > absolutely I already have begun to do it > - let him some time to improve > no rush at all from my side, he has as much time as he wants > - help if you want > I offer to design a custom GUI for it ;) but first I will let you get the functionality right and I can learn from the code as well in the meantime because I am not familiar with the REST API at all :) > The goal of skip internship with us is to build a better code review > system for Pharo. > And we decided to use existing infrastructure instead of building our own > seaside-based yet another server to maintain. > > good choice, afterall pharo already greatly benefits from taking advantage of existing technologies like CI, Cairo, OpenGL, git , mercurial, MongoDB etc . Keep the great work and thanks for motivating me to use and learn Pharo, more and more. > Stef > > >

Nov. 24, 2015

Re: [Pharo-dev] Basic versioning of GitHub repositories from within Pharo

by stepharo

I suggest all interested parties to - review the code of skip - let him some time to improve - help if you want The goal of skip internship with us is to build a better code review system for Pharo. And we decided to use existing infrastructure instead of building our own seaside-based yet another server to maintain. Stef Le 23/11/15 16:25, Skip Lentz a Ã©crit : > Hi everyone, > > As part of my internship I am creating bindings to the GitHub API in > Pharo. > As a prototype and demo, I have created a small tool last week to do > some basic versioning, namely checking out a version, committing a > version and showing a log of commits along with a branch tree. > > Hereâs a screenshot: http://i.imgur.com/iMfWOvp.png > > The repository of the bindings and the tool is here: > http://smalltalkhub.com/#!/~Balletie/GitHub > <http://smalltalkhub.com/#%21/%7EBalletie/GitHub> > To load the tool into your image, execute: > > (ConfigurationOfGitHub project version: #development) load: #tool > > Keep in mind that this is tied to GitHub, since internally it uses the > API. A nice side effect of this is that everything can be done > in-memory. That is, thereâs no local copy on the filesystem. One does > not even need git installed. > > That being said, feel free to take off with my prototype and make it > work with e.g. the LibGit bindings in Pharo. > > Known bug: > - When selecting a different repository from the dropdown while a > version is also selected in the log, one gets a DNU. To work around > this for the time being, just deselect the version before you switch > repositories. > > Let me know what you think and feel free to ask some questions. > > Skip

Nov. 24, 2015

Re: [Pharo-dev] Does Pharo stores original author of methods?

by stepharo

+1 And so far Monticello is much better that having delta because you can still get a complete project without having to reconstruct the complete snapshot from deltas. I could not imagine the amount of code we would have lost else. Veronica in her PhD built a crawler that reconstructs all the deltas based on MC files. Now this is work. Stef Le 23/11/15 17:02, Nicolas Cellier a Ã©crit : > It's not Monticello per se. It's the backend (the server) which is too > naive. > The .mcz must be considered as a unit of exchange between the server > (the repository) and the client (the working copy). And please note > that in Monticello, it's not the only way to exchange data, it can > also be a .mcd (a diff). > > Nothing forces the server to store the .mcz as is. That's just a naive > implementation. Chris Muller demonstrated how to use a database > (magma) as backend... > > 2015-11-23 12:12 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr > <mailto:marcus.denker@inria.fr>>: > > > > On 22 Nov 2015, at 20:12, EuanM <euanmee(a)gmail.com > <mailto:euanmee@gmail.com>> wrote: > > > > Is there any reason against amending Monticello to store and > save all > > author's names? > > It does. *If* you have all the versionsâ¦ but doing anything with > âall the versionsâ > is so slow (you need to download them, unpack themâ¦) that we do > not even have > a tool to show the history of a method. > (getting the oldest should be simpler, if you have complete > history+this .mcz is > there). > > Monticello is meant to be a system to save the complete history of > a project > (if you keep all the MCZ available), but the idea to save every > tiny revision as > a complete snapshot, zip compresses, makes it near impossible to > do anything > with the history in practice. > > With today disks, a practical SCM would allow anyone to have the > *complete* > history on the local disk. Monticello does now allow that in any > practical way. > > > > > Presumably, we'd also want a tool that could extract amnders' names > > all the way back to the first commit of a package? > > > > How many on-line Monticello repositories are in common use? > > > > (I know of SqueakSource.com, Smalltalkhub.com and SqueakSource3) > > > > Are there active administrators for each of those repositories that > > would allow us to update the repositories to use the updated > > Monticello? > > > > On 22 November 2015 at 15:42, Marcus Denker > <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: > >> > >> On 20 Nov 2015, at 14:35, Denis Kudriashov > <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: > >> > >> > >> 2015-11-20 14:21 GMT+01:00 Marcus Denker > <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>>: > >>> > >>> epicea data is not stored forever. It is seasion based and the > shipped > >>> image is > >>> clean. > >> > >> > >> But current source of this info is changes file (maybe > sources). And I > >> remember you planned to store current sources in image. And > such information > >> can be there too. > >> Maybe I miss something? > >> > >> > >> The original author is not really that much of information. And > storing it > >> for every method in the image would take space. > >> > >> As I said: the whole idea of using a source revision control > system is that > >> you have the *complete* history available, but > >> not wasting RAM. > >> > >> Marcus > > > > >

Nov. 24, 2015

Re: [Pharo-dev] Kind of RBRenameMethodRefactoring but for closures?

by Thierry Goubier

Hi Mariano, Le 22/11/2015 23:31, Mariano Martinez Peck a Ã©crit : > > ... > > You know what is funny? I run all AST-Tests-Core from Pharo and NONE > halt on #createBlockFor: ... > I even run all those from Refactoring-Tests-Core. > *So..it seems there is not tests that covers the usage of > #createBlockFor: :(* Ok. I'll have a scan of all the RB tests and add additional tests then. There is an issue John pointed to Nicolai and me that needs solving as well. > BTW, do you image other cases like this? > > > You mean storing those RB rules? I try to collect them if I see some > (or participate to), or remember where I see them. > > > No, I mean the compilation of block closures that would try to bind > "self". Anyway, I will search if I find more. Thanks. > I used to know where the RBRewriteTree chapter was in the Pharo > books, but it seems to have disappeared, so I have recreated a copy > that I'll try to update. > > > > Thanks, please share it with me when you made it because I could not > find it weeks ago. My fork of the Pharo for the enterprise book has it: https://github.com/ThierryGoubier/PharoForTheEnterprise-english But I don't have a CI building it yet. Thierry

Nov. 24, 2015

Re: [Pharo-dev] Does Pharo stores original author of methods?

by EuanM

I did not mean storing all versions. I mean storing all authors of previous veesions. On 23 Nov 2015 11:13, "Marcus Denker" <marcus.denker(a)inria.fr> wrote: > > > On 22 Nov 2015, at 20:12, EuanM <euanmee(a)gmail.com> wrote: > > > > Is there any reason against amending Monticello to store and save all > > author's names? > > It does. *If* you have all the versionsâ¦ but doing anything with âall the > versionsâ > is so slow (you need to download them, unpack themâ¦) that we do not even > have > a tool to show the history of a method. > (getting the oldest should be simpler, if you have complete history+this > .mcz is > there). > > Monticello is meant to be a system to save the complete history of a > project > (if you keep all the MCZ available), but the idea to save every tiny > revision as > a complete snapshot, zip compresses, makes it near impossible to do > anything > with the history in practice. > > With today disks, a practical SCM would allow anyone to have the *complete* > history on the local disk. Monticello does now allow that in any practical > way. > > > > > Presumably, we'd also want a tool that could extract amnders' names > > all the way back to the first commit of a package? > > > > How many on-line Monticello repositories are in common use? > > > > (I know of SqueakSource.com, Smalltalkhub.com and SqueakSource3) > > > > Are there active administrators for each of those repositories that > > would allow us to update the repositories to use the updated > > Monticello? > > > > On 22 November 2015 at 15:42, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > >> > >> On 20 Nov 2015, at 14:35, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> > >> > >> 2015-11-20 14:21 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > >>> > >>> epicea data is not stored forever. It is seasion based and the shipped > >>> image is > >>> clean. > >> > >> > >> But current source of this info is changes file (maybe sources). And I > >> remember you planned to store current sources in image. And such > information > >> can be there too. > >> Maybe I miss something? > >> > >> > >> The original author is not really that much of information. And storing > it > >> for every method in the image would take space. > >> > >> As I said: the whole idea of using a source revision control system is > that > >> you have the *complete* history available, but > >> not wasting RAM. > >> > >> Marcus > > > > >

Nov. 24, 2015

Re: [Pharo-dev] vm crash in SmalltalkImage>garbageCollect

by Mariano Martinez Peck

OK, I made it work by compiling a VM with #checkForLeaks answering 1. I see plenty of leaks but they are all of the pattern "cache tag leak in CM". See a piece of the gdb output: ----------- cache tag leak in CM 0x1f4a8b58 @ 0x1f4a8bfa cache tag leak in CM 0x1f4a9800 @ 0x1f4a98a9 cache tag leak in CM 0x1f4ad8a0 @ 0x1f4ad974 cache tag leak in CM 0x1f4ae380 @ 0x1f4ae3ea cache tag leak in CM 0x1f4ae510 @ 0x1f4ae577 cache tag leak in CM 0x1f4af708 @ 0x1f4af94e checkCodeIntegrity(0) 11637 fwdBlockValid(fwdBlock2) 40450 Program received signal SIGSEGV, Segmentation fault. 0x000ab672 in updatePointersInRangeFromto (memStart=525336576, memEnd=555384320) at /Users/mariano/Pharo/git/pharo-vm/src/vm/gcc3x-cointerp.c:40451 40451 targetObj = longAt(fwdBlock2); ------------- There is none other type of leak displayed. Any idea what does this mean? On Mon, Nov 23, 2015 at 11:28 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > > > On Mon, Nov 23, 2015 at 11:15 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> >> >> On Mon, Nov 23, 2015 at 11:13 PM, Mariano Martinez Peck < >> marianopeck(a)gmail.com> wrote: >> >>> >>> >>> On Mon, Nov 23, 2015 at 9:57 PM, Andrei Chis <chisvasileandrei(a)gmail.com >>> > wrote: >>> >>>> Hi Eliot, >>>> >>>> Is an assert vm the same as a vm compiled with debugging support? >>>> Also can you point me to any documentation about the leak checker. >>>> >>>> >>> I was about to ask the same. I have the VM compiled with debug support >>> and gdb working. I can reproduce the crash. >>> After checking a bit in the VM about what Eliot says, I found out >>> methods like #clearLeakMapAndMapAccessibleObjects and #checkCodeIntegrity:. >>> >>> However, I tried, for example (clearLeakMapAndMapAccessibleObjects to >>> later call checkCodeIntegrity(0) ) from gdb: >>> >>> ------ >>> *fwdBlockValid(fwdBlock2) 40450* >>> >>> *Program received signal SIGSEGV, Segmentation fault.* >>> *0x000ab6d2 in ?? ()* >>> *(gdb) call clearLeakMapAndMapAccessibleObjects()* >>> ------- >>> >>> >>> And I get CPU at 100% never ending. >>> >> >> I forgot to said..I also compiled the VM with a hardcoded #checkForLeaks >> that answers 1 (to force the checker) but that did not work either. >> >> >> >>> >>> >>> Cheers, >>>> Andrei >>>> >>>> On Nov 24, 2015 1:45 AM, "Eliot Miranda" <eliot.miranda(a)gmail.com> >>>> wrote: >>>> > >>>> > Hi Andrei, >>>> > >>>> > On Mon, Nov 23, 2015 at 7:59 AM, Andrei Chis < >>>> chisvasileandrei(a)gmail.com> wrote: >>>> >> >>>> >> Hi, >>>> >> >>>> >> With both the latest and stable vm I have an use case in which the >>>> vm crashed in SmalltalkImage>>garbageCollect. >>>> >> >>>> >> To set up an image that exhibits the failure , execute this with the >>>> latest pharo version: >>>> >> >>>> >> /pharo Pharo.image eval --save "{ { 'ConfigurationOfRubric'. >>>> 'Pharo'. 'Rubric' }. { 'ConfigurationOfGlamourCore'. 'Moose'. 'Glamour' }. >>>> { 'ConfigurationOfGTInspectorCore'. 'Moose'. 'GToolkit' }. { >>>> 'ConfigurationOfGTPlaygroundCore'. 'Moose'. 'GToolkit' }. { >>>> 'ConfigurationOfGTEventRecorder'. 'Moose'. 'GToolkit' }. { >>>> 'ConfigurationOfGTSpotter'. 'Moose'. 'GToolkit' }. } do: [ :spec | Gofer >>>> new smalltalkhubUser: spec second project: spec third; package: spec first; >>>> load ]." >>>> >> >>>> >> ./pharo Pharo.image config >>>> http://www.smalltalkhub.com/mc/Pharo/Pharo50Inbox/main >>>> ConfigurationOfGToolkitCore --install=3.2 >>>> >> >>>> >> Then attempting to run the following code triggers the failure: >>>> >> >>>> >> ./pharo Pharo.image eval --save "TestRunner open model >>>> packageSearchUpdate: 'gt-tests-inspector'; classSearchUpdate: >>>> 'GTInspectorExamplesTest'; runAll" >>>> >> >>>> >> Based on the trace below the failure happens when the >>>> test GTInspectorExamplesTest calls 'Smalltalk>>garbageCollect' in the setUp >>>> method. >>>> >> >>>> >> That call can be removed, however, in other runs the failure happens >>>> in other methods calling Smalltalk>>garbageCollect. >>>> >> >>>> >> Is it possible that this is a bug with the image (some broken >>>> object) or is it a vm bug? >>>> > >>>> > >>>> > The way to test this is to build an assert VM and then use the leak >>>> checker. The leak checker will allow you to narrow down the cause. If the >>>> leak checker shows no corruption then its definitely a GC bug. If there >>>> leak checker does show corruption before GC then one still has to find out >>>> what caused the heap corruption, but you can use the leak checker to narrow >>>> the search. >>>> > >>>> > HTH >>>> > Eliot >>>> >>>> > >>>> >> Cheers, >>>> >> >>>> >> Andrei >>>> >> >>>> >> >>>> >> >>>> >> andrei$ ./pharo Pharo.image eval --save "{ { >>>> 'ConfigurationOfRubric'. 'Pharo'. 'Rubric' }. { >>>> 'ConfigurationOfGlamourCore'. 'Moose'. 'Glamour' }. { >>>> 'ConfigurationOfGTInspectorCore'. 'Moose'. 'GToolkit' }. { >>>> 'ConfigurationOfGTPlaygroundCore'. 'Moose'. 'GToolkit' }. { >>>> 'ConfigurationOfGTEventRecorder'. 'Moose'. 'GToolkit' }. { >>>> 'ConfigurationOfGTSpotter'. 'Moose'. 'GToolkit' }. } do: [ :spec | Gofer >>>> new smalltalkhubUser: spec second project: spec third; package: spec first; >>>> load ]." >>>> >> >>>> >> andrei$ ./pharo Pharo.image config >>>> http://www.smalltalkhub.com/mc/Pharo/Pharo50Inbox/main >>>> ConfigurationOfGToolkitCore --install=3.2 >>>> >> >>>> >> andrei$ ./pharo Pharo.image eval --save "TestRunner open model >>>> packageSearchUpdate: 'gt-tests-inspector'; classSearchUpdate: >>>> 'GTInspectorExamplesTest'; runAll" >>>> >> >>>> >> >>>> >> Segmentation fault Mon Nov 23 16:48:36 2015 >>>> >> >>>> >> >>>> >> >>>> >> https://github.com/pharo-project/pharo-vm.git Commit: >>>> 28d077d8df494ce050ca42c97c892471e8b8740c Date: 2015-10-16 12:02:43 +0200 >>>> By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #15016 >>>> >> >>>> >> >>>> >> C stack backtrace: >>>> >> >>>> >> 0 Pharo 0x0004cacf reportStackState >>>> + 159 >>>> >> >>>> >> >>>> >> >>>> >> Smalltalk stack dump: >>>> >> >>>> >> 0xbffbf1a0 M SmalltalkImage>garbageCollect 0x1fd49e30: a(n) >>>> SmalltalkImage >>>> >> >>>> >> 0xbffbf1c0 I GTInspectorExamplesTest>setUp 0x2126bc80: a(n) >>>> GTInspectorExamplesTest >>>> >> >>>> >> 0x2126cb90 is not a context >>>> >> >>>> >> >>>> >> Most recent primitives >>>> >> >>>> >> @ >>>> >> >>>> >> basicNew >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> basicNew >>>> >> >>>> >> basicNew >>>> >> >>>> >> basicNew >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> shallowCopy >>>> >> >>>> >> new >>>> >> >>>> >> new: >>>> >> >>>> >> new: >>>> >> >>>> >> basicNew >>>> >> >>>> >> basicNew >>>> >> >>>> >> new: >>>> >> >>>> >> basicNew >>>> >> >>>> >> new: >>>> >> >>>> >> replaceFrom:to:with:startingAt: >>>> >> >>>> >> new: >>>> >> >>>> >> basicNew >>>> >> >>>> >> new: >>>> >> >>>> >> replaceFrom:to:with:startingAt: >>>> >> >>>> >> new: >>>> >> >>>> >> basicNew >>>> >> >>>> >> @ >>>> >> >>>> >> new: >>>> >> >>>> >> at:put: >>>> >> >>>> >> at:put: >>>> >> >>>> >> perform:with: >>>> >> >>>> >> perform:with: >>>> >> >>>> >> perform: >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> basicNew >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> basicNew >>>> >> >>>> >> @ >>>> >> >>>> >> new: >>>> >> >>>> >> at:put: >>>> >> >>>> >> at:put: >>>> >> >>>> >> perform:with: >>>> >> >>>> >> perform:with: >>>> >> >>>> >> perform: >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> basicNew >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> new >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> basicNew >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> new: >>>> >> >>>> >> at:put: >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> basicNew >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> new: >>>> >> >>>> >> at:put: >>>> >> >>>> >> at:put: >>>> >> >>>> >> at:put: >>>> >> >>>> >> at:put: >>>> >> >>>> >> new: >>>> >> >>>> >> @ >>>> >> >>>> >> at:put: >>>> >> >>>> >> @ >>>> >> >>>> >> at:put: >>>> >> >>>> >> @ >>>> >> >>>> >> at:put: >>>> >> >>>> >> @ >>>> >> >>>> >> at:put: >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> basicNew >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> basicNew >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> basicNew >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> shallowCopy >>>> >> >>>> >> shallowCopy >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> new: >>>> >> >>>> >> at:put: >>>> >> >>>> >> at:put: >>>> >> >>>> >> at:put: >>>> >> >>>> >> at:put: >>>> >> >>>> >> new: >>>> >> >>>> >> @ >>>> >> >>>> >> at:put: >>>> >> >>>> >> @ >>>> >> >>>> >> at:put: >>>> >> >>>> >> @ >>>> >> >>>> >> at:put: >>>> >> >>>> >> @ >>>> >> >>>> >> at:put: >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> basicNew >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> basicNew >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> basicNew >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> basicNew >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> basicNew >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> basicNew >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> basicNew >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> basicNew >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> basicNew >>>> >> >>>> >> @ >>>> >> >>>> >> @ >>>> >> >>>> >> perform: >>>> >> >>>> >> basicNew >>>> >> >>>> >> new: >>>> >> >>>> >> basicNew >>>> >> >>>> >> new: >>>> >> >>>> >> basicNew >>>> >> >>>> >> new: >>>> >> >>>> >> shallowCopy >>>> >> >>>> >> shallowCopy >>>> >> >>>> >> primUTCMicrosecondsClock >>>> >> >>>> >> // >>>> >> >>>> >> basicNew >>>> >> >>>> >> basicNew >>>> >> >>>> >> new: >>>> >> >>>> >> at:put: >>>> >> >>>> >> at:put: >>>> >> >>>> >> at:put: >>>> >> >>>> >> at:put: >>>> >> >>>> >> value >>>> >> >>>> >> valueNoContextSwitch >>>> >> >>>> >> basicNew >>>> >> >>>> >> new: >>>> >> >>>> >> basicNew >>>> >> >>>> >> new: >>>> >> >>>> >> new: >>>> >> >>>> >> basicNew >>>> >> >>>> >> new: >>>> >> >>>> >> replaceFrom:to:with:startingAt: >>>> >> >>>> >> primitiveGarbageCollect >>>> >> >>>> >> **IncrementalGC** >>>> >> >>>> >> **FullGC** >>>> >> >>>> >> garbageCollectMost >>>> >> >>>> >> **IncrementalGC** >>>> >> >>>> >> basicNew >>>> >> >>>> >> new: >>>> >> >>>> >> someInstance >>>> >> >>>> >> basicNew >>>> >> >>>> >> new: >>>> >> >>>> >> someInstance >>>> >> >>>> >> basicNew >>>> >> >>>> >> new: >>>> >> >>>> >> someInstance >>>> >> >>>> >> new: >>>> >> >>>> >> basicNew >>>> >> >>>> >> new: >>>> >> >>>> >> replaceFrom:to:with:startingAt: >>>> >> >>>> >> primitiveGarbageCollect >>>> >> >>>> >> **IncrementalGC** >>>> >> >>>> >> **FullGC** >>>> >> >>>> >> garbageCollectMost >>>> >> >>>> >> **IncrementalGC** >>>> >> >>>> >> wait >>>> >> >>>> >> shallowCopy >>>> >> >>>> >> shallowCopy >>>> >> >>>> >> signal >>>> >> >>>> >> wait >>>> >> >>>> >> shallowCopy >>>> >> >>>> >> shallowCopy >>>> >> >>>> >> at:put: >>>> >> >>>> >> at:put: >>>> >> >>>> >> at:put: >>>> >> >>>> >> at:put: >>>> >> >>>> >> at:put: >>>> >> >>>> >> at:put: >>>> >> >>>> >> signal >>>> >> >>>> >> wait >>>> >> >>>> >> shallowCopy >>>> >> >>>> >> shallowCopy >>>> >> >>>> >> at:put: >>>> >> >>>> >> at:put: >>>> >> >>>> >> signal >>>> >> >>>> >> new: >>>> >> >>>> >> basicNew >>>> >> >>>> >> new: >>>> >> >>>> >> replaceFrom:to:with:startingAt: >>>> >> >>>> >> primitiveGarbageCollect >>>> >> >>>> >> **IncrementalGC** >>>> >> >>>> >> **FullGC** >>>> >> >>>> >> >>>> >> (Segmentation fault) >>>> >> >>>> >> ./pharo: line 11: 5224 Abort trap: 6 >>>> "$DIR"/"pharo-vm/Pharo.app/Contents/MacOS/Pharo" --headless "$@" >>>> > >>>> > >>>> > >>>> > >>>> > -- >>>> > _,,,^..^,,,_ >>>> > best, Eliot >>>> >>>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > -- > Mariano > http://marianopeck.wordpress.com > -- Mariano http://marianopeck.wordpress.com

Nov. 24, 2015

Re: [Pharo-dev] vm crash in SmalltalkImage>garbageCollect

by Mariano Martinez Peck

OK, I made it work by compiling a VM with #checkForLeaks answering 1. I see plenty of leaks but they are all of the pattern "cache tag leak in CM". See a piece of the gdb output: ----------- cache tag leak in CM 0x1f4a8b58 @ 0x1f4a8bfa cache tag leak in CM 0x1f4a9800 @ 0x1f4a98a9 cache tag leak in CM 0x1f4ad8a0 @ 0x1f4ad974 cache tag leak in CM 0x1f4ae380 @ 0x1f4ae3ea cache tag leak in CM 0x1f4ae510 @ 0x1f4ae577 cache tag leak in CM 0x1f4af708 @ 0x1f4af94e checkCodeIntegrity(0) 11637 fwdBlockValid(fwdBlock2) 40450 Program received signal SIGSEGV, Segmentation fault. 0x000ab672 in updatePointersInRangeFromto (memStart=525336576, memEnd=555384320) at /Users/mariano/Pharo/git/pharo-vm/src/vm/gcc3x-cointerp.c:40451 40451 targetObj = longAt(fwdBlock2); ------------- There is none other type of leak displayed. Any idea what does this mean? On Mon, Nov 23, 2015 at 11:15 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Mon, Nov 23, 2015 at 11:13 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> >> >> On Mon, Nov 23, 2015 at 9:57 PM, Andrei Chis <chisvasileandrei(a)gmail.com> >> wrote: >> >>> Hi Eliot, >>> >>> Is an assert vm the same as a vm compiled with debugging support? >>> Also can you point me to any documentation about the leak checker. >>> >>> >> I was about to ask the same. I have the VM compiled with debug support >> and gdb working. I can reproduce the crash. >> After checking a bit in the VM about what Eliot says, I found out methods >> like #clearLeakMapAndMapAccessibleObjects and #checkCodeIntegrity:. >> >> However, I tried, for example (clearLeakMapAndMapAccessibleObjects to >> later call checkCodeIntegrity(0) ) from gdb: >> >> ------ >> *fwdBlockValid(fwdBlock2) 40450* >> >> *Program received signal SIGSEGV, Segmentation fault.* >> *0x000ab6d2 in ?? ()* >> *(gdb) call clearLeakMapAndMapAccessibleObjects()* >> ------- >> >> >> And I get CPU at 100% never ending. >> > > I forgot to said..I also compiled the VM with a hardcoded #checkForLeaks > that answers 1 (to force the checker) but that did not work either. > > > >> >> >> Cheers, >>> Andrei >>> >>> On Nov 24, 2015 1:45 AM, "Eliot Miranda" <eliot.miranda(a)gmail.com> >>> wrote: >>> > >>> > Hi Andrei, >>> > >>> > On Mon, Nov 23, 2015 at 7:59 AM, Andrei Chis < >>> chisvasileandrei(a)gmail.com> wrote: >>> >> >>> >> Hi, >>> >> >>> >> With both the latest and stable vm I have an use case in which the vm >>> crashed in SmalltalkImage>>garbageCollect. >>> >> >>> >> To set up an image that exhibits the failure , execute this with the >>> latest pharo version: >>> >> >>> >> /pharo Pharo.image eval --save "{ { 'ConfigurationOfRubric'. 'Pharo'. >>> 'Rubric' }. { 'ConfigurationOfGlamourCore'. 'Moose'. 'Glamour' }. { >>> 'ConfigurationOfGTInspectorCore'. 'Moose'. 'GToolkit' }. { >>> 'ConfigurationOfGTPlaygroundCore'. 'Moose'. 'GToolkit' }. { >>> 'ConfigurationOfGTEventRecorder'. 'Moose'. 'GToolkit' }. { >>> 'ConfigurationOfGTSpotter'. 'Moose'. 'GToolkit' }. } do: [ :spec | Gofer >>> new smalltalkhubUser: spec second project: spec third; package: spec first; >>> load ]." >>> >> >>> >> ./pharo Pharo.image config >>> http://www.smalltalkhub.com/mc/Pharo/Pharo50Inbox/main >>> ConfigurationOfGToolkitCore --install=3.2 >>> >> >>> >> Then attempting to run the following code triggers the failure: >>> >> >>> >> ./pharo Pharo.image eval --save "TestRunner open model >>> packageSearchUpdate: 'gt-tests-inspector'; classSearchUpdate: >>> 'GTInspectorExamplesTest'; runAll" >>> >> >>> >> Based on the trace below the failure happens when the >>> test GTInspectorExamplesTest calls 'Smalltalk>>garbageCollect' in the setUp >>> method. >>> >> >>> >> That call can be removed, however, in other runs the failure happens >>> in other methods calling Smalltalk>>garbageCollect. >>> >> >>> >> Is it possible that this is a bug with the image (some broken object) >>> or is it a vm bug? >>> > >>> > >>> > The way to test this is to build an assert VM and then use the leak >>> checker. The leak checker will allow you to narrow down the cause. If the >>> leak checker shows no corruption then its definitely a GC bug. If there >>> leak checker does show corruption before GC then one still has to find out >>> what caused the heap corruption, but you can use the leak checker to narrow >>> the search. >>> > >>> > HTH >>> > Eliot >>> >>> > >>> >> Cheers, >>> >> >>> >> Andrei >>> >> >>> >> >>> >> >>> >> andrei$ ./pharo Pharo.image eval --save "{ { 'ConfigurationOfRubric'. >>> 'Pharo'. 'Rubric' }. { 'ConfigurationOfGlamourCore'. 'Moose'. 'Glamour' }. >>> { 'ConfigurationOfGTInspectorCore'. 'Moose'. 'GToolkit' }. { >>> 'ConfigurationOfGTPlaygroundCore'. 'Moose'. 'GToolkit' }. { >>> 'ConfigurationOfGTEventRecorder'. 'Moose'. 'GToolkit' }. { >>> 'ConfigurationOfGTSpotter'. 'Moose'. 'GToolkit' }. } do: [ :spec | Gofer >>> new smalltalkhubUser: spec second project: spec third; package: spec first; >>> load ]." >>> >> >>> >> andrei$ ./pharo Pharo.image config >>> http://www.smalltalkhub.com/mc/Pharo/Pharo50Inbox/main >>> ConfigurationOfGToolkitCore --install=3.2 >>> >> >>> >> andrei$ ./pharo Pharo.image eval --save "TestRunner open model >>> packageSearchUpdate: 'gt-tests-inspector'; classSearchUpdate: >>> 'GTInspectorExamplesTest'; runAll" >>> >> >>> >> >>> >> Segmentation fault Mon Nov 23 16:48:36 2015 >>> >> >>> >> >>> >> >>> >> https://github.com/pharo-project/pharo-vm.git Commit: >>> 28d077d8df494ce050ca42c97c892471e8b8740c Date: 2015-10-16 12:02:43 +0200 >>> By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #15016 >>> >> >>> >> >>> >> C stack backtrace: >>> >> >>> >> 0 Pharo 0x0004cacf reportStackState + >>> 159 >>> >> >>> >> >>> >> >>> >> Smalltalk stack dump: >>> >> >>> >> 0xbffbf1a0 M SmalltalkImage>garbageCollect 0x1fd49e30: a(n) >>> SmalltalkImage >>> >> >>> >> 0xbffbf1c0 I GTInspectorExamplesTest>setUp 0x2126bc80: a(n) >>> GTInspectorExamplesTest >>> >> >>> >> 0x2126cb90 is not a context >>> >> >>> >> >>> >> Most recent primitives >>> >> >>> >> @ >>> >> >>> >> basicNew >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> basicNew >>> >> >>> >> basicNew >>> >> >>> >> basicNew >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> shallowCopy >>> >> >>> >> new >>> >> >>> >> new: >>> >> >>> >> new: >>> >> >>> >> basicNew >>> >> >>> >> basicNew >>> >> >>> >> new: >>> >> >>> >> basicNew >>> >> >>> >> new: >>> >> >>> >> replaceFrom:to:with:startingAt: >>> >> >>> >> new: >>> >> >>> >> basicNew >>> >> >>> >> new: >>> >> >>> >> replaceFrom:to:with:startingAt: >>> >> >>> >> new: >>> >> >>> >> basicNew >>> >> >>> >> @ >>> >> >>> >> new: >>> >> >>> >> at:put: >>> >> >>> >> at:put: >>> >> >>> >> perform:with: >>> >> >>> >> perform:with: >>> >> >>> >> perform: >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> basicNew >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> basicNew >>> >> >>> >> @ >>> >> >>> >> new: >>> >> >>> >> at:put: >>> >> >>> >> at:put: >>> >> >>> >> perform:with: >>> >> >>> >> perform:with: >>> >> >>> >> perform: >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> basicNew >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> new >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> basicNew >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> new: >>> >> >>> >> at:put: >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> basicNew >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> new: >>> >> >>> >> at:put: >>> >> >>> >> at:put: >>> >> >>> >> at:put: >>> >> >>> >> at:put: >>> >> >>> >> new: >>> >> >>> >> @ >>> >> >>> >> at:put: >>> >> >>> >> @ >>> >> >>> >> at:put: >>> >> >>> >> @ >>> >> >>> >> at:put: >>> >> >>> >> @ >>> >> >>> >> at:put: >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> basicNew >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> basicNew >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> basicNew >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> shallowCopy >>> >> >>> >> shallowCopy >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> new: >>> >> >>> >> at:put: >>> >> >>> >> at:put: >>> >> >>> >> at:put: >>> >> >>> >> at:put: >>> >> >>> >> new: >>> >> >>> >> @ >>> >> >>> >> at:put: >>> >> >>> >> @ >>> >> >>> >> at:put: >>> >> >>> >> @ >>> >> >>> >> at:put: >>> >> >>> >> @ >>> >> >>> >> at:put: >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> basicNew >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> basicNew >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> basicNew >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> basicNew >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> basicNew >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> basicNew >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> basicNew >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> basicNew >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> basicNew >>> >> >>> >> @ >>> >> >>> >> @ >>> >> >>> >> perform: >>> >> >>> >> basicNew >>> >> >>> >> new: >>> >> >>> >> basicNew >>> >> >>> >> new: >>> >> >>> >> basicNew >>> >> >>> >> new: >>> >> >>> >> shallowCopy >>> >> >>> >> shallowCopy >>> >> >>> >> primUTCMicrosecondsClock >>> >> >>> >> // >>> >> >>> >> basicNew >>> >> >>> >> basicNew >>> >> >>> >> new: >>> >> >>> >> at:put: >>> >> >>> >> at:put: >>> >> >>> >> at:put: >>> >> >>> >> at:put: >>> >> >>> >> value >>> >> >>> >> valueNoContextSwitch >>> >> >>> >> basicNew >>> >> >>> >> new: >>> >> >>> >> basicNew >>> >> >>> >> new: >>> >> >>> >> new: >>> >> >>> >> basicNew >>> >> >>> >> new: >>> >> >>> >> replaceFrom:to:with:startingAt: >>> >> >>> >> primitiveGarbageCollect >>> >> >>> >> **IncrementalGC** >>> >> >>> >> **FullGC** >>> >> >>> >> garbageCollectMost >>> >> >>> >> **IncrementalGC** >>> >> >>> >> basicNew >>> >> >>> >> new: >>> >> >>> >> someInstance >>> >> >>> >> basicNew >>> >> >>> >> new: >>> >> >>> >> someInstance >>> >> >>> >> basicNew >>> >> >>> >> new: >>> >> >>> >> someInstance >>> >> >>> >> new: >>> >> >>> >> basicNew >>> >> >>> >> new: >>> >> >>> >> replaceFrom:to:with:startingAt: >>> >> >>> >> primitiveGarbageCollect >>> >> >>> >> **IncrementalGC** >>> >> >>> >> **FullGC** >>> >> >>> >> garbageCollectMost >>> >> >>> >> **IncrementalGC** >>> >> >>> >> wait >>> >> >>> >> shallowCopy >>> >> >>> >> shallowCopy >>> >> >>> >> signal >>> >> >>> >> wait >>> >> >>> >> shallowCopy >>> >> >>> >> shallowCopy >>> >> >>> >> at:put: >>> >> >>> >> at:put: >>> >> >>> >> at:put: >>> >> >>> >> at:put: >>> >> >>> >> at:put: >>> >> >>> >> at:put: >>> >> >>> >> signal >>> >> >>> >> wait >>> >> >>> >> shallowCopy >>> >> >>> >> shallowCopy >>> >> >>> >> at:put: >>> >> >>> >> at:put: >>> >> >>> >> signal >>> >> >>> >> new: >>> >> >>> >> basicNew >>> >> >>> >> new: >>> >> >>> >> replaceFrom:to:with:startingAt: >>> >> >>> >> primitiveGarbageCollect >>> >> >>> >> **IncrementalGC** >>> >> >>> >> **FullGC** >>> >> >>> >> >>> >> (Segmentation fault) >>> >> >>> >> ./pharo: line 11: 5224 Abort trap: 6 >>> "$DIR"/"pharo-vm/Pharo.app/Contents/MacOS/Pharo" --headless "$@" >>> > >>> > >>> > >>> > >>> > -- >>> > _,,,^..^,,,_ >>> > best, Eliot >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > -- > Mariano > http://marianopeck.wordpress.com > -- Mariano http://marianopeck.wordpress.com

Nov. 24, 2015