[Pharo-project] Behavior modification VM crash
let's have some fun and do Object subclass: #Behavior uses: TPureBehavior instanceVariableNames: 'superclass methodDict format layout' classVariableNames: 'ObsoleteSubclasses' poolDictionaries: '' category: 'Kernel-Classes' proceed over the several warnings not to change Behavior and BOOM! :D why would I do this? => we want first class layouts (most probably in 1.5) =============================================================================== StackInterpreter VMMaker-oscog-EstebanLorenzano.139 uuid: 5aa53979-d7d8-4ca3-91fe-cfc3b4109c33 =============================================================================== Recompiling Metaclass (2041/2046) 100% =============================================================================== Notice: Errors in script loaded from script.st =============================================================================== ==== Startup Error: MessageNotUnderstood: Dictionary>>asLowercase Dictionary(Object)>>doesNotUnderstand: #asLowercase ChangeSet>>noteClassStructure: ChangeSet>>changeClass:from: ChangeSet>>event: WeakMessageSend>>valueWithArguments: WeakActionSequenceTrappingErrors>>valueWithArguments:startingFrom: in Block: [answer := each valueWithArguments: anArray] BlockClosure>>on:do: WeakActionSequenceTrappingErrors>>valueWithArguments:startingFrom: WeakActionSequenceTrappingErrors>>valueWithArguments: SystemEventManager(Object)>>triggerEvent:withArguments: ... =============================================================================== CoInterpreter VMMaker-oscog-EstebanLorenzano.139 uuid: 5aa53979-d7d8-4ca3-91fe-cfc3b4109c33 =============================================================================== Recompiling Class class (924/2046) 45% =============================================================================== Notice: Errors in script loaded from script.st =============================================================================== ==== Startup Error: MessageNotUnderstood: ByteSymbol>>copyTraitExpression ByteSymbol(Object)>>doesNotUnderstand: #copyTraitExpression ClassBuilder>>mutate:to: in Block: [:oldSubclass | ... Array(SequenceableCollection)>>do: ClassBuilder>>mutate:to: ClassBuilder>>mutate:to: in Block: [:oldSubclass | ... Array(SequenceableCollection)>>do: ClassBuilder>>mutate:to: ClassBuilder>>mutate:to: in Block: [:oldSubclass | ... Array(SequenceableCollecti ... =============================================================================== now and then the CogVM crashes due to a SEGFAULT. Under one of the old Squeak VMs it compiles but depending on the VM version, has issues maintaining a sane state. So this is most certainly a VM issue and not a bug in the image side code. As far as I remember the CogVM opens a modified image without issues... best cami
On 22 Mar 2012, at 14:45, Camillo Bruni wrote:
let's have some fun and do
Object subclass: #Behavior uses: TPureBehavior instanceVariableNames: 'superclass methodDict format layout' classVariableNames: 'ObsoleteSubclasses' poolDictionaries: '' category: 'Kernel-Classes'
proceed over the several warnings not to change Behavior and BOOM! :D
Check classNameIndex and thisClassIndex in the VM implementation. They are typically the hardcoded indices into the expected object layout of Class objects. And you just changed the layout -> BOOM! magic ;) I don't know how much overhead it is to examine such kind of indices dynamically, but we do deduce indices based on inst var names to be able to support the different object layouts. For my stuff, I do that at VM startup, which would not help you. David did it dynamically for the Process class and checked the object identity of the class I think, to know when to update the index table after a layout change. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
On 2012-03-22, at 15:06, Stefan Marr wrote:
On 22 Mar 2012, at 14:45, Camillo Bruni wrote:
let's have some fun and do
Object subclass: #Behavior uses: TPureBehavior instanceVariableNames: 'superclass methodDict format layout' classVariableNames: 'ObsoleteSubclasses' poolDictionaries: '' category: 'Kernel-Classes'
proceed over the several warnings not to change Behavior and BOOM! :D
Check classNameIndex and thisClassIndex in the VM implementation. They are typically the hardcoded indices into the expected object layout of Class objects.
And you just changed the layout -> BOOM! magic ;)
I don't know how much overhead it is to examine such kind of indices dynamically, but we do deduce indices based on inst var names to be able to support the different object layouts. For my stuff, I do that at VM startup, which would not help you. David did it dynamically for the Process class and checked the object identity of the class I think, to know when to update the index table after a layout change.
right. I guess I will have to move it to some further position... although I have an old image with: Behavior subclass: #ClassDescription layout: PointerLayout uses: TClassAndTraitDescription slots: { #instanceVariables => Slot. #organization => Slot. #layout => Slot. } classSlots: {} globals: '' category: #'Kernel-Classes' which works under said Cog version :/. I guess I will just have to find some older VM which will support the changes
On Thu, Mar 22, 2012 at 7:26 AM, Camillo Bruni <camillobruni@gmail.com>wrote:
On 2012-03-22, at 15:06, Stefan Marr wrote:
On 22 Mar 2012, at 14:45, Camillo Bruni wrote:
let's have some fun and do
Object subclass: #Behavior uses: TPureBehavior instanceVariableNames: 'superclass methodDict format layout' classVariableNames: 'ObsoleteSubclasses' poolDictionaries: '' category: 'Kernel-Classes'
proceed over the several warnings not to change Behavior and BOOM! :D
Check classNameIndex and thisClassIndex in the VM implementation. They are typically the hardcoded indices into the expected object layout
of Class objects.
And you just changed the layout -> BOOM! magic ;)
I don't know how much overhead it is to examine such kind of indices
dynamically, but we do deduce indices based on inst var names to be able to support the different object layouts.
For my stuff, I do that at VM startup, which would not help you.
They would be expensive to recompute all the time (they're used in debug printing). But they're not expensive to compute. So they could be recomputed easily. See below.
David did it dynamically for the Process class and checked the object identity of the class I think, to know when to update the index table after a layout change.
right. I guess I will have to move it to some further position... although I have an old image with:
Behavior subclass: #ClassDescription layout: PointerLayout uses: TClassAndTraitDescription slots: { #instanceVariables => Slot. #organization => Slot. #layout => Slot. } classSlots: {} globals: '' category: #'Kernel-Classes'
which works under said Cog version :/. I guess I will just have to find some older VM which will support the changes
I think we should make the VM work for this. classNameIndex and thisClassIndex should only be used for debug printing, at least thats my intent, and it would be possible to flush them and recompute them as a side-effect of e.g. a flushCache primitive. Camilo, would you create a reproducible case for me, an image that applies this change at start-up? Thanks. Also, can we please get into the habit of cc'ing vm-dev for issues that touch on the VM? I ask this so that subsequent searching for VM issues can be confined to a search of vm-dev archives. Again AdvThanksance. -- best, Eliot
On 2012-03-22, at 17:26, Eliot Miranda wrote:
On Thu, Mar 22, 2012 at 7:26 AM, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2012-03-22, at 15:06, Stefan Marr wrote:
On 22 Mar 2012, at 14:45, Camillo Bruni wrote:
let's have some fun and do
Object subclass: #Behavior uses: TPureBehavior instanceVariableNames: 'superclass methodDict format layout' classVariableNames: 'ObsoleteSubclasses' poolDictionaries: '' category: 'Kernel-Classes'
proceed over the several warnings not to change Behavior and BOOM! :D
Check classNameIndex and thisClassIndex in the VM implementation. They are typically the hardcoded indices into the expected object layout of Class objects.
And you just changed the layout -> BOOM! magic ;)
I don't know how much overhead it is to examine such kind of indices dynamically, but we do deduce indices based on inst var names to be able to support the different object layouts. For my stuff, I do that at VM startup, which would not help you.
They would be expensive to recompute all the time (they're used in debug printing). But they're not expensive to compute. So they could be recomputed easily. See below.
David did it dynamically for the Process class and checked the object identity of the class I think, to know when to update the index table after a layout change.
right. I guess I will have to move it to some further position... although I have an old image with:
Behavior subclass: #ClassDescription layout: PointerLayout uses: TClassAndTraitDescription slots: { #instanceVariables => Slot. #organization => Slot. #layout => Slot. } classSlots: {} globals: '' category: #'Kernel-Classes'
which works under said Cog version :/. I guess I will just have to find some older VM which will support the changes
I think we should make the VM work for this. classNameIndex and thisClassIndex should only be used for debug printing, at least thats my intent, and it would be possible to flush them and recompute them as a side-effect of e.g. a flushCache primitive.
Camilo, would you create a reproducible case for me, an image that applies this change at start-up? Thanks.
Also, can we please get into the habit of cc'ing vm-dev for issues that touch on the VM? I ask this so that subsequent searching for VM issues can be confined to a search of vm-dev archives. Again AdvThanksance.
Submitted a bug report here: http://code.google.com/p/cog/issues/detail?id=76 the attached *.st files fail under Cog / StackVM. It would be indeed nice if they would work. best cami
On Thu, Mar 22, 2012 at 3:32 PM, Camillo Bruni <camillobruni@gmail.com>wrote:
On 2012-03-22, at 17:26, Eliot Miranda wrote:
On Thu, Mar 22, 2012 at 7:26 AM, Camillo Bruni <camillobruni@gmail.com>
wrote:
On 2012-03-22, at 15:06, Stefan Marr wrote:
On 22 Mar 2012, at 14:45, Camillo Bruni wrote:
let's have some fun and do
Object subclass: #Behavior uses: TPureBehavior instanceVariableNames: 'superclass methodDict format layout' classVariableNames: 'ObsoleteSubclasses' poolDictionaries: '' category: 'Kernel-Classes'
proceed over the several warnings not to change Behavior and BOOM! :D
Check classNameIndex and thisClassIndex in the VM implementation. They are typically the hardcoded indices into the expected object
layout of Class objects.
And you just changed the layout -> BOOM! magic ;)
I don't know how much overhead it is to examine such kind of indices
dynamically, but we do deduce indices based on inst var names to be able to support the different object layouts.
For my stuff, I do that at VM startup, which would not help you.
They would be expensive to recompute all the time (they're used in debug printing). But they're not expensive to compute. So they could be recomputed easily. See below.
David did it dynamically for the Process class and checked the object identity of the class I think, to know when to update the index table after a layout change.
right. I guess I will have to move it to some further position... although I have an old image with:
Behavior subclass: #ClassDescription layout: PointerLayout uses: TClassAndTraitDescription slots: { #instanceVariables => Slot. #organization => Slot. #layout => Slot. } classSlots: {} globals: '' category: #'Kernel-Classes'
which works under said Cog version :/. I guess I will just have to find some older VM which will support the changes
I think we should make the VM work for this. classNameIndex and thisClassIndex should only be used for debug printing, at least thats my intent, and it would be possible to flush them and recompute them as a side-effect of e.g. a flushCache primitive.
Camilo, would you create a reproducible case for me, an image that applies this change at start-up? Thanks.
Also, can we please get into the habit of cc'ing vm-dev for issues that touch on the VM? I ask this so that subsequent searching for VM issues can be confined to a search of vm-dev archives. Again AdvThanksance.
Submitted a bug report here: http://code.google.com/p/cog/issues/detail?id=76
the attached *.st files fail under Cog / StackVM. It would be indeed nice if they would work.
Which maybe it will one day if you can put in the effort to describe how to reproduce the bug properly. There's no pointer to a suitable image. There are no instructions beyond "use these files". How about a link to an image, plus a small script that files in the files? Or even better how about constructing an image that does this at startup so that the VM maintainers only have to fire up the image instead of wasting time setting up files?
best cami
-- best, Eliot
On Mar 22, 2012, at 2:45 PM, Camillo Bruni wrote:
let's have some fun and do
Object subclass: #Behavior uses: TPureBehavior instanceVariableNames: 'superclass methodDict format layout' classVariableNames: 'ObsoleteSubclasses' poolDictionaries: '' category: 'Kernel-Classes'
proceed over the several warnings not to change Behavior and BOOM! :D why would I do this? => we want first class layouts (most probably in 1.5)
whoooo so exciting. Stef
=============================================================================== StackInterpreter VMMaker-oscog-EstebanLorenzano.139 uuid: 5aa53979-d7d8-4ca3-91fe-cfc3b4109c33 =============================================================================== Recompiling Metaclass (2041/2046) 100% =============================================================================== Notice: Errors in script loaded from script.st =============================================================================== ==== Startup Error: MessageNotUnderstood: Dictionary>>asLowercase Dictionary(Object)>>doesNotUnderstand: #asLowercase ChangeSet>>noteClassStructure: ChangeSet>>changeClass:from: ChangeSet>>event: WeakMessageSend>>valueWithArguments: WeakActionSequenceTrappingErrors>>valueWithArguments:startingFrom: in Block: [answer := each valueWithArguments: anArray] BlockClosure>>on:do: WeakActionSequenceTrappingErrors>>valueWithArguments:startingFrom: WeakActionSequenceTrappingErrors>>valueWithArguments: SystemEventManager(Object)>>triggerEvent:withArguments: ...
=============================================================================== CoInterpreter VMMaker-oscog-EstebanLorenzano.139 uuid: 5aa53979-d7d8-4ca3-91fe-cfc3b4109c33 =============================================================================== Recompiling Class class (924/2046) 45% =============================================================================== Notice: Errors in script loaded from script.st =============================================================================== ==== Startup Error: MessageNotUnderstood: ByteSymbol>>copyTraitExpression ByteSymbol(Object)>>doesNotUnderstand: #copyTraitExpression ClassBuilder>>mutate:to: in Block: [:oldSubclass | ... Array(SequenceableCollection)>>do: ClassBuilder>>mutate:to: ClassBuilder>>mutate:to: in Block: [:oldSubclass | ... Array(SequenceableCollection)>>do: ClassBuilder>>mutate:to: ClassBuilder>>mutate:to: in Block: [:oldSubclass | ... Array(SequenceableCollecti ...
===============================================================================
now and then the CogVM crashes due to a SEGFAULT. Under one of the old Squeak VMs it compiles but depending on the VM version, has issues maintaining a sane state.
So this is most certainly a VM issue and not a bug in the image side code. As far as I remember the CogVM opens a modified image without issues...
best cami
On 22 March 2012 18:26, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Mar 22, 2012, at 2:45 PM, Camillo Bruni wrote:
let's have some fun and do
Object subclass: #Behavior    uses: TPureBehavior    instanceVariableNames: 'superclass methodDict format layout'    classVariableNames: 'ObsoleteSubclasses'    poolDictionaries: ''    category: 'Kernel-Classes'
proceed over the several warnings not to change Behavior and BOOM! :D why would I do this? => we want first class layouts (most probably in 1.5)
whoooo so exciting.
Only over VM's dead segfaulted body! :)
Stef
-- Best regards, Igor Stasenko.
participants (6)
-
Camillo Bruni -
Camillo Bruni -
Eliot Miranda -
Igor Stasenko -
Stefan Marr -
Stéphane Ducasse