It would be possible to start the update with the required error handlers 
around it, but unless you really had to do it, you're better off using a 
fixed image.

Levente

On Tue, 23 Aug 2016, marcel.taeumel wrote:

> 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.
>
>