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

[Laura Perez Cerrato]

Experiencing the same issue, and got around it the same way you describe.

-Laura Perez Cerrato

On 21 August 2016 at 17:55, 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.
>>>>>
>>>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160822/83c1be3a/attachment-0001.htm