Does anyone recognize this glitch in our trunk update processing? (was: [Vm-dev] fails on Mac)

Levente Uzonyi leves at
Sun Aug 21 20:55:55 UTC 2016

Same here. I think the code changes during the update and the old code 
on the stack causes the problem.


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> 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, 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>:
>>>> I just tried running the vmmaker-build script on my iMac with weirdly bad
>>>> results.
>>>> The vm it downloads is the 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 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.

More information about the Vm-dev mailing list