[Pharo-project] Behavior modification VM crash

Eliot Miranda eliot.miranda at gmail.com
Fri Mar 23 13:53:36 EDT 2012


Camillo,

On Fri, Mar 23, 2012 at 5:13 AM, Camillo Bruni <camillobruni at gmail.com>wrote:

>
> On 2012-03-22, at 23:41, Eliot Miranda wrote:
>
> >
> >
> > On Thu, Mar 22, 2012 at 3:32 PM, Camillo Bruni <camillobruni at 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 at 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?
>
> you know command line?
> you know images?
>
> cool here we go....
>
>
> path/to/my/crashing/vm path/to/anImage.iamge
> absolute/path/to/the/scripts/attached/to/the/bug/regport.st


this is simply an insult on your part.  You cannot even bother to specify a
Pharo version. I use Squeak, and Newspeak.  I don't use Pharo except for
investigating VM bugs, for the benefit of the Pharo community as well as
for Cog's overall quality.  I give my limited time to the Pharo community
in providing a significantly improved VM.  Is it too much to ask that you
can provide helpful bug reports that save me time?  Or do you think I am
your lackey to exploit and insult?


>
> here we go (mario)
>
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120323/4c92ecff/attachment-0001.html>


More information about the Pharo-dev mailing list