<div dir="ltr"><div><div>There might be another possibility: destroy the progress bar in the preamble.<br></div>How to detect the progress bar is left as an exercize (translate: I just don't know, maybe also by walking the stack).<br></div>Reopen the progress bar in postscript.<br></div><div class="gmail_extra"><br><div class="gmail_quote">2016-08-22 17:57 GMT+02:00 Chris Muller <span dir="ltr"><<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This isn't the first time our changes have caused update hiccups. I<br>
think it just comes with the territory. Easiest to just save off<br>
another image that is beyond the problem and move on from there.<br>
<div class="HOEnZb"><div class="h5"><br>
On Mon, Aug 22, 2016 at 7:36 AM, Bert Freudenberg <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>> wrote:<br>
> Seen it, discussed with Marcel but we don't have a good idea yet how to work<br>
> around it.<br>
><br>
> The only thing I can think of is to walk up the sender chain and restart<br>
> some context above the one referencing the old instance layout. Maybe an<br>
> exception handler in the updater that restarts updating in this specific<br>
> case?<br>
><br>
> - Bert -<br>
><br>
><br>
> On Sun, Aug 21, 2016 at 10:55 PM, Levente Uzonyi <<a href="mailto:leves@caesar.elte.hu">leves@caesar.elte.hu</a>><br>
> wrote:<br>
>><br>
>><br>
>> Same here. I think the code changes during the update and the old code on<br>
>> the stack causes the problem.<br>
>><br>
>> Levente<br>
>><br>
>><br>
>> On Sun, 21 Aug 2016, Chris Muller wrote:<br>
>><br>
>>><br>
>>> I've definitely experienced the exact same problem, and got around it<br>
>>> the same way, restarting the method and proceeding. Very strange.<br>
>>><br>
>>><br>
>>> On Sun, Aug 21, 2016 at 3:13 PM, David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>><br>
>>> wrote:<br>
>>>><br>
>>>><br>
>>>> Moving from vm-dev to squeak-dev because it is a trunk update stream<br>
>>>> question.<br>
>>>> Follow ups to squeak-dev please.<br>
>>>><br>
>>>> Does anyone recognize this problem?<br>
>>>><br>
>>>> We have an issue in trunk update processing that prevents a full update<br>
>>>> without manual intervention. This does not affect the 5.1 release, but<br>
>>>> it would be good to fix it so that the update from 5.0 to 5.1 can be<br>
>>>> reproduced in a continuous integration test.<br>
>>>><br>
>>>> To reproduce: Start with Squeak5.0-15113.image, set the update URL<br>
>>>> preference<br>
>>>> to <a href="http://source.squeak.org/trunk" rel="noreferrer" target="_blank">http://source.squeak.org/trunk</a><wbr>, and do an "update from server".<br>
>>>><br>
>>>> The error first appears when beginning to process the update-mt.378.mcm<br>
>>>> update map. The problem is related to updating the progress bar with<br>
>>>> ProgressInitiationException.<br>
>>>><br>
>>>> When the failure occurs, the debugger (see attached image) seems to<br>
>>>> show an array access being interpreted as if the array was an instance<br>
>>>> of StrikeFont. Per Nicolas' note below, it may be related to showing<br>
>>>> the progress bar while updating it.<br>
>>>><br>
>>>> I can restart the update process from the debugger from<br>
>>>> SystemProgressMorph>>position:<wbr>label:min:max: in the stack frame, and the<br>
>>>> update proceeds. The error happens several more times, then at some<br>
>>>> point<br>
>>>> it seems to go away, so apparently the problem was fixed at some later<br>
>>>> point in the update stream.<br>
>>>><br>
>>>> Does anyone recognize this problem? Can we work around it by changing<br>
>>>> one<br>
>>>> or more of the update maps?<br>
>>>><br>
>>>> Thanks,<br>
>>>> Dave<br>
>>>><br>
>>>><br>
>>>> On Fri, Aug 19, 2016 at 10:30:30PM +0200, Nicolas Cellier wrote:<br>
>>>>><br>
>>>>><br>
>>>>> yes, this is a problem I encountered both in 32 and 64 bits squeak<br>
>>>>> while<br>
>>>>> updating.<br>
>>>>><br>
>>>>> I think it's related to showing the progress bar while updating the<br>
>>>>> progress bar. It's a Squeak trunk update problem, not a VM problem.<br>
>>>>><br>
>>>>> If some class layout change, but some block is still active (yeah, did<br>
>>>>> you<br>
>>>>> see how many blocks we traverse just to change display of a bar...),<br>
>>>>> then<br>
>>>>> the old block has invalid inst var offsets (offsets to the old object<br>
>>>>> that<br>
>>>>> now has become a new object with new layout).<br>
>>>>><br>
>>>>> In an interactive image, just close the debugger and relaunch the<br>
>>>>> update.<br>
>>>>> In an headless automated process, well... We should have fixed the<br>
>>>>> update<br>
>>>>> or start from a newer artifact...<br>
>>>>><br>
>>>>> 2016-08-19 21:32 GMT+02:00 tim Rowledge <<a href="mailto:tim@rowledge.org">tim@rowledge.org</a>>:<br>
>>>>>><br>
>>>>>><br>
>>>>>> I just tried running the vmmaker-build script on my iMac with weirdly<br>
>>>>>> bad<br>
>>>>>> results.<br>
>>>>>><br>
>>>>>> The vm it downloads is the CogSpur.app-16.18.3692 version. Whilst<br>
>>>>>> trying<br>
>>>>>> to do the update part of the process I had several *very* odd failures<br>
>>>>>> where an object in a block was mistaken for nil during a message send.<br>
>>>>>> For<br>
>>>>>> example in a progress bar update (which I can???t provide a log for<br>
>>>>>> since the<br>
>>>>>> log got overwritten later) a line<br>
>>>>>> (bars at: index)<br>
>>>>>> lead to a nil is not indexable halt. Yet in inspecting the prior<br>
>>>>>> stackframe the bars object was a perfectly normal array of progress<br>
>>>>>> bars. A<br>
>>>>>> similar but not identical problem happened during another attempt.<br>
>>>>>><br>
>>>>>> Attempting to filein the BuildSqueakSpurTrunkVMMaker.st file failed<br>
>>>>>> when<br>
>>>>>> the vm exploded with no visible log.<br>
>>>>>><br>
>>>>>> Now I???m attempting to repeat that with a new 5.1rc1 vm & already up<br>
>>>>>> to<br>
>>>>>> date 5.1rc1 image. Which has sorta-worked, in a rather odd manner. It<br>
>>>>>> got<br>
>>>>>> to the final save and quit but when I start the supposedly prepared<br>
>>>>>> image<br>
>>>>>> there is a problem with it trying to filein that file. I can???t tell<br>
>>>>>> right<br>
>>>>>> now if it relates to the manual filein I started or if something got<br>
>>>>>> added<br>
>>>>>> as a deferred action? Or maybe it???s a side-effect of the filein<br>
>>>>>> having a<br>
>>>>>> save & quit? Not come across this before.<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> So far as I can tell it did complete the filein, so maybe all is well.<br>
>>>>>><br>
>>>><br>
>>><br>
><br>
><br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div>