This isn't the first time our changes have caused update hiccups.  I
think it just comes with the territory.  Easiest to just save off
another image that is beyond the problem and move on from there.

On Mon, Aug 22, 2016 at 7:36 AM, Bert Freudenberg <bert at freudenbergs.de> 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 -
>
>
> On Sun, Aug 21, 2016 at 10:55 PM, Levente Uzonyi <leves at caesar.elte.hu>
> 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 mail.msen.com>
>>> 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 at rowledge.org>:
>>>>>>
>>>>>>
>>>>>> 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.
>>>>>>
>>>>
>>>
>
>
>
>