Nicolas Cellier wrote
> There's yet another possibility, in a preamble:
> - clone the old SystemProgressMorph class,
> - mutate all instances to the clone class
> 
> Don't use class rename and class removal, because the system will do too
> much clean up.
> instead hack at a lower level
> 
> 2016-08-23 4:03 GMT+02:00 David T. Lewis <

> lewis at .msen

> >:
> 
>> On Mon, Aug 22, 2016 at 02:36:09PM +0200, Bert Freudenberg wrote:
>> > Seen it, discussed with Marcel but we don't have a good idea yet how to
>> > work around it.
>> >
>> > The only thing I can think of is to walk up the sender chain and
>> restart
>> > some context above the one referencing the old instance layout. Maybe
>> an
>> > exception handler in the updater that restarts updating in this
>> specific
>> > case?
>> >
>> > - Bert -
>> >
>>
>> I don't see a good place to put an exception handler, at least not
>> without
>> making things even more complicated than they already are.
>>
>> It looks like the the direct reference to instance var 'bars' is where we
>> encounter the problem. Presumably the old code in a block is refering to
>> an ivar slot in SystemProgressMorph that used to point to the 'vars'
>> array,
>> but that is now pointing to the 'font' ivar.
>>
>> And indeed I see now that Marcel found and fixed this issue in
>> Morphic-mt.1198,
>> so that accessor methods will now be used instead of direct references to
>> the variables.
>>
>> But we still have the problem of a SystemProgressMorph evaluating an
>> older
>> block that was created with an earlier version of the
>> SystemProgressMorph>>position:label:min:max: method, so the update stream
>> processing still fails if the update processing was started before
>> Morphic-mt.1198 was loaded.
>>
>> A partial workaround is to modify #position:label:min:max: to use an
>> accessor
>> for 'bars' prior to starting the update processing. This prevents the
>> error
>> condition that we are discussing here, but unfortunately it also results
>> in a couple of merge dialogs for the modified methods, so the update
>> still
>> requires manual intervention.
>>
>> Dave
>>
>>
>> >
>> > On Sun, Aug 21, 2016 at 10:55 PM, Levente Uzonyi <

> leves at .elte

> >
>> > wrote:
>> >
>> > >
>> > > Same here. I think the code changes during the update and the old
>> code
>> on
>> > > the stack causes the problem.
>> > >
>> > > Levente
>> > >
>> > >
>> > > On Sun, 21 Aug 2016, Chris Muller wrote:
>> > >
>> > >
>> > >> I've definitely experienced the exact same problem, and got around
>> it
>> > >> the same way, restarting the method and proceeding.  Very strange.
>> > >>
>> > >>
>> > >> On Sun, Aug 21, 2016 at 3:13 PM, David T. Lewis <

> lewis at .msen

> >
>> > >> wrote:
>> > >>
>> > >>>
>> > >>> Moving from vm-dev to squeak-dev because it is a trunk update
>> stream
>> > >>> question.
>> > >>> Follow ups to squeak-dev please.
>> > >>>
>> > >>> Does anyone recognize this problem?
>> > >>>
>> > >>> We have an issue in trunk update processing that prevents a full
>> update
>> > >>> without manual intervention. This does not affect the 5.1 release,
>> but
>> > >>> it would be good to fix it so that the update from 5.0 to 5.1 can
>> be
>> > >>> reproduced in a continuous integration test.
>> > >>>
>> > >>> To reproduce: Start with Squeak5.0-15113.image, set the update URL
>> > >>> preference
>> > >>> to http://source.squeak.org/trunk, and do an "update from server".
>> > >>>
>> > >>> The error first appears when beginning to process the
>> update-mt.378.mcm
>> > >>> update map. The problem is related to updating the progress bar
>> with
>> > >>> ProgressInitiationException.
>> > >>>
>> > >>> When the failure occurs, the debugger (see attached image) seems to
>> > >>> show an array access being interpreted as if the array was an
>> instance
>> > >>> of StrikeFont. Per Nicolas' note below, it may be related to
>> showing
>> > >>> the progress bar while updating it.
>> > >>>
>> > >>> I can restart the update process from the debugger from
>> > >>> SystemProgressMorph>>position:label:min:max: in the stack frame,
>> and the
>> > >>> update proceeds. The error happens several more times, then at some
>> point
>> > >>> it seems to go away, so apparently the problem was fixed at some
>> later
>> > >>> point in the update stream.
>> > >>>
>> > >>> Does anyone recognize this problem? Can we work around it by
>> changing one
>> > >>> or more of the update maps?
>> > >>>
>> > >>> Thanks,
>> > >>> Dave
>> > >>>
>> > >>>
>> > >>> On Fri, Aug 19, 2016 at 10:30:30PM +0200, Nicolas Cellier wrote:
>> > >>>
>> > >>>>
>> > >>>> yes, this is a problem I encountered both in 32 and 64 bits squeak
>> while
>> > >>>> updating.
>> > >>>>
>> > >>>> I think it's related to showing the progress bar while updating
>> the
>> > >>>> progress bar. It's a Squeak trunk update problem, not a VM
>> problem.
>> > >>>>
>> > >>>> If some class layout change, but some block is still active (yeah,
>> did
>> > >>>> you
>> > >>>> see how many blocks we traverse just to change display of a
>> bar...),
>> > >>>> then
>> > >>>> the old block has invalid inst var offsets (offsets to the old
>> object
>> > >>>> that
>> > >>>> now has become a new object with new layout).
>> > >>>>
>> > >>>> In an interactive image, just close the debugger and relaunch the
>> > >>>> update.
>> > >>>> In an headless automated process, well... We should have fixed the
>> > >>>> update
>> > >>>> or start from a newer artifact...
>> > >>>>
>> > >>>> 2016-08-19 21:32 GMT+02:00 tim Rowledge <

> tim@

> >:
>> > >>>>
>> > >>>>>
>> > >>>>> I just tried running the vmmaker-build script on my iMac with
>> weirdly
>> > >>>>> bad
>> > >>>>> results.
>> > >>>>>
>> > >>>>> The vm it downloads is the CogSpur.app-16.18.3692 version. Whilst
>> > >>>>> trying
>> > >>>>> to do the update part of the process I had several *very* odd
>> failures
>> > >>>>> where an object in a block was mistaken for nil during a message
>> send.
>> > >>>>> For
>> > >>>>> example in a progress bar update (which I can???t provide a log
>> for
>> > >>>>> since the
>> > >>>>> log got overwritten later) a line
>> > >>>>> (bars at: index)
>> > >>>>> lead to a nil is not indexable halt. Yet in inspecting the prior
>> > >>>>> stackframe the bars object was a perfectly normal array of
>> progress
>> > >>>>> bars. A
>> > >>>>> similar but not identical problem happened during another
>> attempt.
>> > >>>>>
>> > >>>>> Attempting to filein the BuildSqueakSpurTrunkVMMaker.st file
>> failed
>> > >>>>> when
>> > >>>>> the vm exploded with no visible log.
>> > >>>>>
>> > >>>>> Now I???m attempting to repeat that with a new 5.1rc1 vm &
>> already
>> up
>> > >>>>> to
>> > >>>>> date 5.1rc1 image. Which has sorta-worked, in a rather odd
>> manner.
>> It
>> > >>>>> got
>> > >>>>> to the final save and quit but when I start the supposedly
>> prepared
>> > >>>>> image
>> > >>>>> there is a problem with it trying to filein that file. I can???t
>> tell
>> > >>>>> right
>> > >>>>> now if it relates to the manual filein I started or if something
>> got
>> > >>>>> added
>> > >>>>> as a deferred action? Or maybe it???s a side-effect of the filein
>> > >>>>> having a
>> > >>>>> save & quit? Not come across this before.
>> > >>>>>
>> > >>>>>
>> > >>>>>
>> > >>>>> So far as I can tell it did complete the filein, so maybe all is
>> well.
>> > >>>>>
>> > >>>>>
>> > >>>
>> > >>
>>
>> >
>>
>>
>>

Hi, there.

It is, unfortunately, not possible to turn back time and rewrite history.
;-) There is several important code that makes excessive use of instVar
accesses such as in SystemProgressMorph or HandMorph. Making any change in
their class layout while using some of their methods will provoke a strange
error. This could only be changed by a VM that keeps old class
layouts/schemata around for some longer time until there is no old compiled
method on any stack anymore.

Usually, restarting the update process helps here. There is no way to fix
that in order to interactively update from 5.0 to 5.1 without any errors.

However, we have an update script that updates build 15113, which is
effectively Squeak 5.0 to the latest trunk. Here is the script:
https://github.com/squeak-smalltalk/squeak-app/blob/master/prepare_image.st
And here is the image build 15113:
http://files.squeak.org/base/Squeak-trunk/base.zip

We use that the create bundles with the latest alpha, beta, rc versions.

Best,
Marcel



--
View this message in context: http://forum.world.st/Re-Does-anyone-recognize-this-glitch-in-our-trunk-update-processing-was-Vm-dev-buildspurtrunkvmmaker-tp4912130p4912305.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.