Segfault!!!!! Could it be due to #become: or #valueUnpreemptively ? (see PharoClassInstaller>>migrateClasses:to:using:) Dump: Segmentation fault Smalltalk stack dump: 0xbffb58a0 M [] in PharoClassInstaller>migrateClasses:to:using: 0x2172b068: a(n) PharoClassInstaller 0xbffb3f88 M BlockClosure>ensure: 0x21779288: a(n) BlockClosure 0xbffb3fb4 M BlockClosure>valueUnpreemptively 0x21779288: a(n) BlockClosure 0xbffb3fd4 I PharoClassInstaller>migrateClasses:to:using: 0x2172b068: a(n) PharoClassInstaller 0xbffb4000 I SlotClassBuilder>migrateClasses: 0x2172b138: a(n) SlotClassBuilder 0xbffb4020 M SlotClassBuilder>apply: 0x2172b138: a(n) SlotClassBuilder 0xbffb4048 M SlotClassBuilder>build 0x2172b138: a(n) SlotClassBuilder 0xbffb4064 M PharoClassInstaller class(AbstractClassInstaller class)>make: 0x1f9d440c: a(n) PharoClassInstaller class 0xbffb4080 M OldClassBuilderAdapter>name:inEnvironment:subclassOf:type:instanceVariableNames:classVariableNames:poolDictionaries:category: 0x2172a278: a(n) OldClassBuilderAdapter 0xbffb476c M [] in MCClassDefinition>createClass 0x2146d174: a(n) MCClassDefinition 0xbffb4788 M BlockClosure>on:do: 0x2172a200: a(n) BlockClosure 0xbffb47b4 M MCClassDefinition>createClass 0x2146d174: a(n) MCClassDefinition 0xbffb47d8 I MCClassDefinition>load 0x2146d174: a(n) MCClassDefinition 0xbffb47f0 M MCClassDefinition(MCDefinition)>addMethodAdditionTo: 0x2146d174: a(n) MCClassDefinition 0xbffb4810 M [] in MCPackageLoader>tryToLoad: 0x2140a3c8: a(n) MCPackageLoader 0xbffb482c M BlockClosure>on:do: 0x2172a104: a(n) BlockClosure 0xbffb484c M MCPackageLoader>tryToLoad: 0x2140a3c8: a(n) MCPackageLoader 0xbffb4868 M [] in MCPackageLoader>basicLoadDefinitions 0x2140a3c8: a(n) MCPackageLoader 0xbffb489c M [] in OrderedCollection(Collection)>do:displayingProgress:every: 0x21477678: a(n) OrderedCollection 0xbffb0efc M OrderedCollection>do: 0x21477678: a(n) OrderedCollection 0xbffb0f2c M [] in OrderedCollection(Collection)>do:displayingProgress:every: 0x21477678: a(n) OrderedCollection 0xbffb0f48 M BlockClosure>cull: 0x214969dc: a(n) BlockClosure 0xbffb0f68 M [] in Job>run 0x21496a04: a(n) Job 0xbffb0f84 M BlockClosure>on:do: 0x21497014: a(n) BlockClosure 0xbffb0fa8 M [] in Job>run 0x21496a04: a(n) Job 0xbffb0fc8 M BlockClosure>ensure: 0x21496ad0: a(n) BlockClosure 0xbffb0fe8 M Job>run 0x21496a04: a(n) Job 0xbffb1000 M MorphicUIManager(UIManager)>displayProgress:from:to:during: 0x1fbfab0c: a(n) MorphicUIManager 0xbffb1030 I ByteString(String)>displayProgressFrom:to:during: 0x209a3f20: a(n) ByteString 0xbffb105c M OrderedCollection(Collection)>do:displayingProgress:every: 0x21477678: a(n) OrderedCollection 0xbffb1080 M OrderedCollection(Collection)>do:displayingProgress: 0x21477678: a(n) OrderedCollection 0xbffb10a0 M MCPackageLoader>basicLoadDefinitions 0x2140a3c8: a(n) MCPackageLoader 0xbffb1ec4 I [] in MCPackageLoader>basicLoad 0x2140a3c8: a(n) MCPackageLoader 0xbffb1ee0 M BlockClosure>on:do: 0x21478ffc: a(n) BlockClosure 0xbffb1f0c I [] in MCPackageLoader>handleLoadErrorsDuring: 0x2140a3c8: a(n) MCPackageLoader 0xbffb1f28 M BlockClosure>on:do: 0x21479068: a(n) BlockClosure 0xbffb1f50 I MCPackageLoader>handleLoadErrorsDuring: 0x2140a3c8: a(n) MCPackageLoader 0xbffb1f74 I [] in MCPackageLoader>basicLoad 0x2140a3c8: a(n) MCPackageLoader 0xbffb1f94 M BlockClosure>ensure: 0x21478f80: a(n) BlockClosure 0xbffb1fb8 I MCPackageLoader>basicLoad 0x2140a3c8: a(n) MCPackageLoader 0xbffb1fd8 I [] in MCPackageLoader>loadWithNameLike: 0x2140a3c8: a(n) MCPackageLoader 0xbffb1ff8 M BlockClosure>ensure: 0x21478b50: a(n) BlockClosure 0xbffb2024 I MCPackageLoader>useChangeSetNamed:during: 0x2140a3c8: a(n) MCPackageLoader 0xbffb204c I MCPackageLoader>useNewChangeSetNamedLike:during: 0x2140a3c8: a(n) MCPackageLoader 0xbffb2074 I MCPackageLoader>loadWithNameLike: 0x2140a3c8: a(n) MCPackageLoader 0xbffb209c I MCVersionLoader>loadWithNameLike: 0x2140a0e0: a(n) MCVersionLoader 0xbffad750 I [] in MCVersionLoader>load 0x2140a0e0: a(n) MCVersionLoader 0xbffad770 M BlockClosure>ensure: 0x2140a184: a(n) BlockClosure 0xbffad798 I RPackageSet class>withCacheDo: 0x1fb96f88: a(n) RPackageSet class 0xbffad7bc I MCVersionLoader>load 0x2140a0e0: a(n) MCVersionLoader 0xbffad7dc I MetacelloGoferLoad(GoferLoad)>execute 0x2140a0d0: a(n) MetacelloGoferLoad 0xbffad800 M [] in MetacelloLoadingMCSpecLoader(MetacelloCommonMCSpecLoader)>loadPackageDirective:gofer: 0x21409e74: a(n) MetacelloLoadingMCSpecLoader 0xbffad834 M [] in MetacelloLoadingMCSpecLoader(MetacelloCommonMCSpecLoader)>loadPackageDirective:gofer: 0x21409e74: a(n) MetacelloLoadingMCSpecLoader 0xbffad84c M MetacelloPharo30Platform(MetacelloPlatform)>do:displaying: 0x1fcacac0: a(n) MetacelloPharo30Platform 0xbffad870 M MetacelloLoadingMCSpecLoader(MetacelloCommonMCSpecLoader)>loadPackageDirective:gofer: 0x21409e74: a(n) MetacelloLoadingMCSpecLoader 0xbffad898 I MetacelloLinearLoadDirective(MetacelloVersionLoadDirective)>loadPackageDirective:gofer: 0x213c6cbc: a(n) MetacelloLinearLoadDirective 0xbffb1724 M MetacelloPackageLoadDirective>loadUsing:gofer: 0x213cec08: a(n) MetacelloPackageLoadDirective 0xbffb174c M [] in MetacelloLinearLoadDirective(MetacelloVersionLoadDirective)>loadLinearLoadDirective:gofer: 0x213c6ab0: a(n) MetacelloLinearLoadDirective 0xbffb176c M OrderedCollection>do: 0x213c70c0: a(n) OrderedCollection 0xbffb1788 M MetacelloLinearLoadDirective(MetacelloVersionLoadDirective)>loadLinearLoadDirective:gofer: 0x213c6ab0: a(n) MetacelloLinearLoadDirective 0xbffb17a8 M MetacelloLinearLoadDirective>loadUsing:gofer: 0x213c6cbc: a(n) MetacelloLinearLoadDirective 0xbffb17d0 M [] in MetacelloLinearLoadDirective(MetacelloVersionLoadDirective)>loadLinearLoadDirective:gofer: 0x213a379c: a(n) MetacelloLinearLoadDirective 0xbffb17f0 M OrderedCollection>do: 0x213c6cd0: a(n) OrderedCollection 0xbffb180c M MetacelloLinearLoadDirective(MetacelloVersionLoadDirective)>loadLinearLoadDirective:gofer: 0x213a379c: a(n) MetacelloLinearLoadDirective 0xbffb182c M MetacelloLinearLoadDirective>loadUsing:gofer: 0x213c6ab0: a(n) MetacelloLinearLoadDirective 0xbffb1854 M [] in MetacelloLinearLoadDirective(MetacelloVersionLoadDirective)>loadLinearLoadDirective:gofer: 0x213a379c: a(n) MetacelloLinearLoadDirective 0xbffb1874 M OrderedCollection>do: 0x213a37b0: a(n) OrderedCollection 0xbffb1898 I MetacelloLinearLoadDirective(MetacelloVersionLoadDirective)>loadLinearLoadDirective:gofer: 0x213a379c: a(n) MetacelloLinearLoadDirective 0xbffb976c I MetacelloLinearLoadDirective>loadUsing:gofer: 0x213a379c: a(n) MetacelloLinearLoadDirective 0xbffb9798 I MetacelloLinearLoadDirective(MetacelloVersionLoadDirective)>loadWithPolicy: 0x213a379c: a(n) MetacelloLinearLoadDirective 0xbffb97bc I MetacelloLoaderPolicy>load 0x21400830: a(n) MetacelloLoaderPolicy 0xbffb97dc I MetacelloFetchingMCSpecLoader>doLoad 0x213a36d4: a(n) MetacelloFetchingMCSpecLoader 0xbffb9800 I [] in MetacelloMCVersion>doLoadRequiredFromArray: 0x213a2ff4: a(n) MetacelloMCVersion 0xbffb9818 M MetacelloPharo30Platform(MetacelloPlatform)>do:displaying: 0x1fcacac0: a(n) MetacelloPharo30Platform 0xbffb984c I [] in MetacelloMCVersion>doLoadRequiredFromArray: 0x213a2ff4: a(n) MetacelloMCVersion 0xbffb986c M BlockClosure>ensure: 0x213a3404: a(n) BlockClosure 0xbffb989c I MetacelloMCVersion>doLoadRequiredFromArray: 0x213a2ff4: a(n) MetacelloMCVersion 0xbffb8754 I MetacelloMCVersion>load 0x213a2ff4: a(n) MetacelloMCVersion 0xbffb8774 I ConfigurationOfPhratch class>loadBleedingEdge 0x213a0124: a(n) ConfigurationOfPhratch class 0xbffb878c M UndefinedObject()>? 0x1f500004: a(n) UndefinedObject 0xbffb87bc I OpalCompiler>evaluate 0x2139d354: a(n) OpalCompiler 0xbffb87e8 I SmalltalkEditor>evaluateSelectionAndDo: 0x21350720: a(n) SmalltalkEditor 0xbffb880c I SmalltalkEditor>evaluateSelection 0x21350720: a(n) SmalltalkEditor 0xbffb882c I [] in PluggableTextMorph>doIt 0x213151c0: a(n) PluggableTextMorph 0xbffb8854 I [] in PluggableTextMorph>handleEdit: 0x213151c0: a(n) PluggableTextMorph 0xbffb8874 I TextMorphForEditView(TextMorph)>handleEdit: 0x21315ed8: a(n) TextMorphForEditView 0xbffb889c I PluggableTextMorph>handleEdit: 0x213151c0: a(n) PluggableTextMorph 0xbffb8f7c I PluggableTextMorph>doIt 0x213151c0: a(n) PluggableTextMorph 0xbffb8f9c I [] in SmalltalkEditor class>buildSmalltalkEditorKeymappingsOn: 0x1f7a53bc: a(n) SmalltalkEditor class 0xbffb8fb8 M BlockClosure>cull: 0x20cef928: a(n) BlockClosure 0xbffb8fd4 M BlockClosure>cull:cull: 0x20cef928: a(n) BlockClosure 0xbffb8ff4 M BlockClosure>cull:cull:cull: 0x20cef928: a(n) BlockClosure 0xbffb9020 I KMCategoryBinding>completeMatch:buffer: 0x21321a1c: a(n) KMCategoryBinding 0xbffb904c I [] in KMKeymap>notifyCompleteMatchTo:buffer: 0x20cf3e98: a(n) KMKeymap 0xbffb9070 M Array(SequenceableCollection)>do: 0x2139cf44: a(n) Array 0xbffb9098 I KMKeymap>notifyCompleteMatchTo:buffer: 0x20cf3e98: a(n) KMKeymap 0xbffb7f98 M KMKeymap>onMatchWith:notify:andDo: 0x20cf3e98: a(n) KMKeymap 0xbffb7fc8 M [] in KMCategory>onMatchWith:notify:andDo: 0x20cf3550: a(n) KMCategory 0xbffb7ff0 M Set>do: 0x2139cf54: a(n) Set 0xbffb800c M KMCategory>onMatchWith:notify:andDo: 0x20cf3550: a(n) KMCategory 0xbffb8030 M KMCategoryBinding>verifyMatchWith:notifying:thenDoing: 0x21321a1c: a(n) KMCategoryBinding 0xbffb8058 M [] in KMDispatcher>dispatch: 0x21321940: a(n) KMDispatcher 0xbffb8078 M OrderedCollection>do: 0x2139ce2c: a(n) OrderedCollection 0xbffb809c M KMDispatcher>dispatch: 0x21321940: a(n) KMDispatcher 0xbffb7730 M KMTarget>dispatch: 0x2132195c: a(n) KMTarget 0xbffb7750 M [] in KMDispatchChain>dispatch: 0x2139ccf8: a(n) KMDispatchChain 0xbffb7778 I KMDispatchChain>do: 0x2139ccf8: a(n) KMDispatchChain 0xbffb7794 M KMDispatchChain>dispatch: 0x2139ccf8: a(n) KMDispatchChain 0xbffb77bc I KMDispatcher>dispatchKeystroke: 0x21315fc8: a(n) KMDispatcher 0xbffb77d8 M TextMorphForEditView(Morph)>dispatchKeystrokeForEvent: 0x21315ed8: a(n) TextMorphForEditView 0xbffb7800 I TextMorphForEditView(TextMorph)>handleKeystroke: 0x21315ed8: a(n) TextMorphForEditView 0xbffb781c M KeyboardEvent>sentTo: 0x2139cca0: a(n) KeyboardEvent 0xbffb7838 M TextMorphForEditView(Morph)>handleEvent: 0x21315ed8: a(n) TextMorphForEditView 0xbffb7854 M TextMorphForEditView(Morph)>handleFocusEvent: 0x21315ed8: a(n) TextMorphForEditView 0xbffb787c M [] in HandMorph>sendFocusEvent:to:clear: 0x1fabfbb8: a(n) HandMorph 0xbffb7898 M BlockClosure>on:do: 0x2139cbac: a(n) BlockClosure 0xbffb6eec M WorldMorph(PasteUpMorph)>becomeActiveDuring: 0x1fabfaa4: a(n) WorldMorph 0xbffb6f10 M HandMorph>sendFocusEvent:to:clear: 0x1fabfbb8: a(n) HandMorph 0xbffb6f38 M HandMorph>sendEvent:focus:clear: 0x1fabfbb8: a(n) HandMorph 0xbffb6f5c M HandMorph>sendKeyboardEvent: 0x1fabfbb8: a(n) HandMorph 0xbffb6f88 M HandMorph>handleEvent: 0x1fabfbb8: a(n) HandMorph 0xbffb6fb4 M HandMorph>processEvents 0x1fabfbb8: a(n) HandMorph 0xbffb6fcc M [] in WorldState>doOneCycleNowFor: 0x1fabfad8: a(n) WorldState 0xbffb6ff0 M Array(SequenceableCollection)>do: 0x1fabfc34: a(n) Array 0xbffb700c M WorldState>handsDo: 0x1fabfad8: a(n) WorldState 0xbffb7028 M WorldState>doOneCycleNowFor: 0x1fabfad8: a(n) WorldState 0xbffb7044 M WorldState>doOneCycleFor: 0x1fabfad8: a(n) WorldState 0xbffb7060 M WorldMorph>doOneCycle 0x1fabfaa4: a(n) WorldMorph 0xbffb7080 I [] in MorphicUIManager>spawnNewProcess 0x1fbfab0c: a(n) MorphicUIManager 0xbffb70a0 I [] in BlockClosure>newProcess 0x2135fa6c: a(n) BlockClosure Most recent primitives compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: at:put: basicNew instVarAt: instVarAt:put: instVarAt: instVarAt:put: instVarAt: instVarAt:put: instVarAt: instVarAt:put: instVarAt: instVarAt:put: instVarAt: instVarAt:put: instVarAt: instVarAt:put: instVarAt: instVarAt:put: instVarAt: instVarAt:put: instVarAt: instVarAt:put: instVarAt: instVarAt:put: instVarAt: instVarAt:put: instVarAt: instVarAt:put: instVarAt: instVarAt:put: at:put: elementsForwardIdentityTo: basicNew new: someInstance nextInstance at:put: new: replaceFrom:to:with:startingAt: new: shallowCopy species new: species new: replaceFrom:to:with:startingAt: species new: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: species new: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: species new: replaceFrom:to:with:startingAt: species new: replaceFrom:to:with:startingAt: species new: replaceFrom:to:with:startingAt: species new: replaceFrom:to:with:startingAt: shallowCopy species new: species new: replaceFrom:to:with:startingAt: species new: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: species new: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: species new: replaceFrom:to:with:startingAt: species new: replaceFrom:to:with:startingAt: species new: replaceFrom:to:with:startingAt: species new: replaceFrom:to:with:startingAt: species new: compare:with:collated: at:put: compare:with:collated: compare:with:collated: at:put: compare:with:collated: compare:with:collated: compare:with:collated: at:put: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: at:put: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: at:put: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: at:put: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: at:put: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: at:put: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: at:put: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: at:put: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: at:put: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: at:put: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: at:put: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: compare:with:collated: at:put: basicNew instVarAt: instVarAt:put: instVarAt: instVarAt:put: instVarAt: instVarAt:put: instVarAt: instVarAt:put: instVarAt: instVarAt:put: instVarAt: instVarAt:put: instVarAt: instVarAt:put: instVarAt: instVarAt:put: instVarAt: instVarAt:put: instVarAt: instVarAt:put: instVarAt: instVarAt:put: instVarAt: instVarAt:put: instVarAt: instVarAt:put: instVarAt: instVarAt:put: at:put: elementsForwardIdentityTo: elementsForwardIdentityTo: /usr/local/bin/pharo-ui: line 11: 17173 Abort trap: 6 "$DIR"/"pharo-vm/Pharo.app/Contents/MacOS/Pharo" "$@" On 24 avr. 2014, at 13:48, Marcus Denker <marcus.denker@inria.fr> wrote:

On 24 Apr 2014, at 13:44, jannik laval <jannik.laval@gmail.com> wrote:

...

Hi pharoers,

I am trying to load Phratch in the latest Pharo3.0 Installer Mac (image+vm), and Pharo crashes during the install.

Yes, and I have no clue why.

Marcus

2014-04-24 20:44 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:

Again, cc'ing vm-dev is courteous.

On Thu, Apr 24, 2014 at 4:58 AM, Camille Teruel <camille.teruel@gmail.com>wrote:

...

Segfault!!!!!

Could it be due to #become: or #valueUnpreemptively ? (see PharoClassInstaller>>migrateClasses:to:using:)

I suspect the become. Thats the last primitive. I suspect it's something to do with become on machine code. I suspect some of my recent changes have not been integrated. e.g. VMMaker.oscog-eem.669.

Hi Eliot, no, it is way behind ! The https://github.com/pharo-project/pharo-vm/ master head is marked as merged with VMMaker.oscog-eem.333 though the merge is very partial. There are also some changes that have been picked from further MC versions, quite randomly IMO (most are related to the Spur VM and are of no value for COG!), but the MC versions are not marked as merged this time. As for the platform sources, I have no idea what/when was the last merge with your svn branch... As I already ranted about, there have been a lot of cosmetic changes (like reformatting some methods) which now are a drag causing many conflicts at each MC merge operation... I've cancelled most of these in my https://github.com/nicolas-cellier-aka-nice/pharo-vm nicedevel branch just to see a bit clearer. It could be a better start for integrating your changes. But synchronizing the svn changes with the MC changes is not that easy; doing it manually is error prone, it should be automated. For this reason, the all-in-one git repo is superior IMO, despite the small MC-git complications. I think the fastest strategy for catching up with Spur would be to re-apply the Pharo changes to the svn/VMMaker.oscog head one by one, rather than the opposite, but I'm not the maintainer. Igor, Esteban and co may have a different idea about it.

-- best, Eliot

On Thu, Apr 24, 2014 at 1:43 PM, Esteban Lorenzano <estebanlm@gmail.com>wrote:

On 24 Apr 2014, at 22:13, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:

2014-04-24 20:44 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:

...

Again, cc'ing vm-dev is courteous.

On Thu, Apr 24, 2014 at 4:58 AM, Camille Teruel <camille.teruel@gmail.com

...

wrote:

...

Segfault!!!!!

Could it be due to #become: or #valueUnpreemptively ? (see PharoClassInstaller>>migrateClasses:to:using:)

I suspect the become. Thats the last primitive. I suspect it's something to do with become on machine code. I suspect some of my recent changes have not been integrated. e.g. VMMaker.oscog-eem.669.

Hi Eliot, no, it is way behind ! The https://github.com/pharo-project/pharo-vm/ master head is marked as merged with VMMaker.oscog-eem.333 though the merge is very partial. There are also some changes that have been picked from further MC versions, quite randomly IMO (most are related to the Spur VM and are of no value for COG!), but the MC versions are not marked as merged this time. As for the platform sources, I have no idea what/when was the last merge with your svn branch...

As I already ranted about, there have been a lot of cosmetic changes (like reformatting some methods) which now are a drag causing many conflicts at each MC merge operation... I've cancelled most of these in my https://github.com/nicolas-cellier-aka-nice/pharo-vm nicedevel branch just to see a bit clearer. It could be a better start for integrating your changes. But synchronizing the svn changes with the MC changes is not that easy; doing it manually is error prone, it should be automated. For this reason, the all-in-one git repo is superior IMO, despite the small MC-git complications.

I think the fastest strategy for catching up with Spur would be to re-apply the Pharo changes to the svn/VMMaker.oscog head one by one, rather than the opposite, but I'm not the maintainer. Igor, Esteban and co may have a different idea about it.

no, I was thinking more or less the same… but still did not looked at it deeply :)

btw… I do not know which randomly picked changes you are talking about. I certainly stopped doing integrations when Eliot started to commit spur stuff, to wait until is more or less ready (bah, with Clement we tried once and it was not worthy, so we rolled back). then… other stuff: I also don’t know about random methods reformatted. I know I reformatted some, but those I worked on (usually not in VMMaker, with minor exceptions). Of course, I’m not the only one working on those sources, but I certainly did many changes with the years.

Finally: ok, vm shouldn’t crash… but this bug was not vm related but a bad integration (in the new class builder) we rollbacked. That’s why it was not copied to vm-dev :)

At last for the core VM classes (ignore plugins) I wish you would integrate by integrating your ephemeron and NativeBoost changes into my tip. I think you're losing a lot of goodness coming form the continuous integration and testing my colleague Bob Westergaard does at Cadence. It worries me that the Pharo VM is buggy. I don't think it needs to be. And please don't take this as a criticism. It's more my anxiety.

cheers, Esteban

cheers!

...

-- best, Eliot

-- best, Eliot

2014-04-24 22:43 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com>:

On 24 Apr 2014, at 22:13, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:

2014-04-24 20:44 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:

...

Again, cc'ing vm-dev is courteous.

On Thu, Apr 24, 2014 at 4:58 AM, Camille Teruel <camille.teruel@gmail.com

...

wrote:

...

Segfault!!!!!

Could it be due to #become: or #valueUnpreemptively ? (see PharoClassInstaller>>migrateClasses:to:using:)

I suspect the become. Thats the last primitive. I suspect it's something to do with become on machine code. I suspect some of my recent changes have not been integrated. e.g. VMMaker.oscog-eem.669.

Hi Eliot, no, it is way behind ! The https://github.com/pharo-project/pharo-vm/ master head is marked as merged with VMMaker.oscog-eem.333 though the merge is very partial. There are also some changes that have been picked from further MC versions, quite randomly IMO (most are related to the Spur VM and are of no value for COG!), but the MC versions are not marked as merged this time. As for the platform sources, I have no idea what/when was the last merge with your svn branch...

As I already ranted about, there have been a lot of cosmetic changes (like reformatting some methods) which now are a drag causing many conflicts at each MC merge operation... I've cancelled most of these in my https://github.com/nicolas-cellier-aka-nice/pharo-vm nicedevel branch just to see a bit clearer. It could be a better start for integrating your changes. But synchronizing the svn changes with the MC changes is not that easy; doing it manually is error prone, it should be automated. For this reason, the all-in-one git repo is superior IMO, despite the small MC-git complications.

I think the fastest strategy for catching up with Spur would be to re-apply the Pharo changes to the svn/VMMaker.oscog head one by one, rather than the opposite, but I'm not the maintainer. Igor, Esteban and co may have a different idea about it.

no, I was thinking more or less the same… but still did not looked at it deeply :)

btw… I do not know which randomly picked changes you are talking about. I certainly stopped doing integrations when Eliot started to commit spur stuff, to wait until is more or less ready (bah, with Clement we tried once and it was not worthy, so we rolled back). then… other stuff: I also don’t know about random methods reformatted. I know I reformatted some, but those I worked on (usually not in VMMaker, with minor exceptions). Of course, I’m not the only one working on those sources, but I certainly did many changes with the years.

It's easy for me to say, because I did the job of tracing the differences when tracking bug https://pharo.fogbugz.com/f/cases/11130 And since git is a super tool, all is publicly traced. So here is the major source of cosmetic changes: the scripts for applying the transformation (self var: #foo ...) -> <var: #foo type: ... > have been applied separately in pharo branch, but with a different layout (space after :) like Dave did in interpreter VM, but unlike Eliot did in .oscog branch if I remember correctly. Then a few other formatting have been done manually. Normally after a merge they are not shown... But since the last merge wirth 333 was partial, we can't use merge from MC, we are forced to use changes that show all the diffs, otherwise we'll miss some of the changes not merged in further merges. Thoses changes can be cancelled by re-applying Eliot's version. You can check on my branch UndoBlankChanges https://github.com/nicolas-cellier-aka-nice/pharo-vm/commit/7ee237a851f2470c... As for the random changes, they are all marked LucFabresse (I think an effect of older gitfiletree). I don't think they are really random: it's more like an aborted merge that was partially reverted. So logically, the things that were not reverted were harmless (the Spur related things). There was certainly a good reason for wanting to merge (like work on simulator maybe) And reverting was probably a good decision at that time because Spur introduction was wausing some Cog regressions. My point is not to denigrate Luc's or Esteban's work, maintaining a parallel branch is complex enough! But when you are searching for a specific bug like those differences appear as random and are parasiting... And when it's time to cancel the debt toward Eliot's branch, that can be disturbing : those methods conflict because of author and time stamp, as I said probably a former gitfiletree bug... You can check the changes in my branch revertLucFabresseAheadChanges https://github.com/nicolas-cellier-aka-nice/pharo-vm/commit/847c254168d0b246... Looking at history, the merge was with Eliot's 406: https://github.com/nicolas-cellier-aka-nice/pharo-vm/commits/a05cda7fb80d891... The last thing I did was to apply Eliot's changes that were not applied in last merge with 333. This is in fixMergeWithEliotVersion333. In fact, it's better to merge with 334, because 333 had some snafu... https://github.com/nicolas-cellier-aka-nice/pharo-vm/commit/8d97c34571adc305... ancestors... ------ But as I said, I would rather throw all that work away and proceed differently, starting from Spur and merging pharo-vm. So what are these changes? There are all the changes related to making VMMaker work in pharo. Pharo API is diverging a bit from squeak over time, especially for the simulator (graphics/forms) and the generator part (file system). IMO, the best would be for squeak to catch up file system changes, but it's only an opinion... For most of the rest, we could arrange to cooperate and integrate some changes for Pharo support / or just add a compatibility package in Pharo branch. Then there are the really essential changes: ephemerons (might be superseded by Spur?) and NB. These are relatively well delimited and should not be a major problem to integrate back. Then the changes of platform files... Most of them should be integrated back in Eliot's svn branch, but they are behind for now. Last, all the CMakeVMMaker work is huge but well separated for now - until tty integrate them back :) and PharoVMMaker, well, is for the pharo configuration obviously. I probably forgotten a few, but IMO, it's not a huge work this way around.

Finally: ok, vm shouldn’t crash… but this bug was not vm related but a bad integration (in the new class builder) we rollbacked. That’s why it was not copied to vm-dev :)

cheers, Esteban

Yes, since it's in the replacement for ClassBuilder, a danger zone... Maybe something like executing a method not correctly recompiled, while the receiver layout has changed? or vice versa...

...

-- best, Eliot

Yes it looks like there is a bug in the slot class builder. I also have a job failing since #30830 the stacktrace: LayoutEmptyScope(Object)>>error: LayoutEmptyScope(LayoutAbstractScope)>>rebase:to: LayoutClassScope>>rebase:to: LayoutClassScope>>rebase:to: LayoutClassScope>>rebase:to: LayoutClassScope>>rebase:to: LayoutClassScope>>rebase:to: LayoutClassScope>>rebase:to: LayoutClassScope>>rebase:to: LayoutClassScope>>rebase:to: LayoutClassScope>>rebase:to: FixedLayout(ObjectLayout)>>reshapeFrom:to: ClassModificationPropagation>>propagate:to: ClassModificationPropagation class>>propagate:to: ClassModification(AbstractClassModification)>>propagate in Block: [ :subclass | propagations add: (ClassModification...etc... Metaclass>>subclassesDo: in Block: [ :aSubclass | ... Array(SequenceableCollection)>>do: MCFileTreeFileUtils class(Class)>>subclassesDo: Metaclass>>subclassesDo: ClassModification(AbstractClassModification)>>propagate SlotClassBuilder>>applyAndUpdateSharedVariableOrSharedPool: in Block: [ :old :new | ... SlotClassBuilder>>track:during: SlotClassBuilder>>applyAndUpdateSharedVariableOrSharedPool: SlotClassBuilder>>applySharedVariableOrPoolChange: SlotClassBuilder>>apply: SlotClassBuilder>>build PharoClassInstaller class(AbstractClassInstaller class)>>make: OldClassBuilderAdapter>>name:inEnvironment:subclassOf:type:instanceVariableNames:classVariableNames:poolDictionaries:category: MCClassDefinition>>createClass in Block: [ ... BlockClosure>>on:do: Le 24 avr. 2014 à 13:59, Henrik Johansen a écrit :

On 24 Apr 2014, at 1:48 , Marcus Denker <marcus.denker@inria.fr> wrote:

...

On 24 Apr 2014, at 13:44, jannik laval <jannik.laval@gmail.com> wrote:

...

Hi pharoers,

I am trying to load Phratch in the latest Pharo3.0 Installer Mac (image+vm), and Pharo crashes during the install.

Yes, and I have no clue why.

Marcus

The package I tried loads fine in 80829, but crashes in 80830, so there’s something in that update which needs to be revisited.

Cheers, Henry

On 24 Apr 2014, at 2:21 , Marcus Denker <marcus.denker@inria.fr> wrote:

On 24 Apr 2014, at 14:04, Christophe Demarey <Christophe.Demarey@inria.fr> wrote:

...

Yes it looks like there is a bug in the slot class builder. I also have a job failing since #30830

Yes, this is already here:

https://pharo.fogbugz.com/f/cases/13223/Error-Should-not-happen-in-rebase-to

Marcus

If I revert (comment out classModification propagate) SlotClassBuilder >> #applyAndUpdateSharedVariableOrSharedPool: classModification ^ self track: classModification during: [ :old :new | installer classDefinitionChangedFrom: old to: new by: classModification. classModification propagate ]. in a 80830 image, loading works fine. … but I guess that change might be the entire point of the patch? Cheers, Henry

On 24 Apr 2014, at 14:57, Camille Teruel <camille.teruel@gmail.com> wrote:

On 24 avr. 2014, at 14:37, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:

...

On 24 Apr 2014, at 2:21 , Marcus Denker <marcus.denker@inria.fr> wrote:

...

On 24 Apr 2014, at 14:04, Christophe Demarey <Christophe.Demarey@inria.fr> wrote:

...

Yes it looks like there is a bug in the slot class builder. I also have a job failing since #30830

Yes, this is already here:

https://pharo.fogbugz.com/f/cases/13223/Error-Should-not-happen-in-rebase-to

Marcus

If I revert (comment out classModification propagate) SlotClassBuilder >> #applyAndUpdateSharedVariableOrSharedPool: classModification ^ self track: classModification during: [ :old :new | installer classDefinitionChangedFrom: old to: new by: classModification. classModification propagate ].

in a 80830 image, loading works fine.

… but I guess that change might be the entire point of the patch?

Yes removing this line will reintroduce the subclass bug. Moreover I think this line is not the cause but a symptom revealer (cf my other mails about classes that have wrong layout). Now I think the segfault is because of a wrong class format somewhere.

So we do another update with the postscript. if that fails, we revert so not all builds are broken. Do we then revert just that method? Or really all updates to 829? Marcus