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

[Chris Muller]

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