<div dir="ltr"><div><div><div><div>There's yet another possibility, in a preamble:<br></div>- clone the old SystemProgressMorph class,<br></div>- mutate all instances to the clone class<br><br></div>Don't use class rename and class removal, because the system will do too much clean up.<br></div>instead hack at a lower level<br></div><div class="gmail_extra"><br><div class="gmail_quote">2016-08-23 4:03 GMT+02:00 David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Aug 22, 2016 at 02:36:09PM +0200, Bert Freudenberg wrote:<br>
> Seen it, discussed with Marcel but we don't have a good idea yet how to<br>
> work 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>
</span>I don't see a good place to put an exception handler, at least not without<br>
making things even more complicated than they already are.<br>
<br>
It looks like the the direct reference to instance var 'bars' is where we<br>
encounter the problem. Presumably the old code in a block is refering to<br>
an ivar slot in SystemProgressMorph that used to point to the 'vars' array,<br>
but that is now pointing to the 'font' ivar.<br>
<br>
And indeed I see now that Marcel found and fixed this issue in Morphic-mt.1198,<br>
so that accessor methods will now be used instead of direct references to<br>
the variables.<br>
<br>
But we still have the problem of a SystemProgressMorph evaluating an older<br>
block that was created with an earlier version of the<br>
SystemProgressMorph>>position:<wbr>label:min:max: method, so the update stream<br>
processing still fails if the update processing was started before<br>
Morphic-mt.1198 was loaded.<br>
<br>
A partial workaround is to modify #position:label:min:max: to use an accessor<br>
for 'bars' prior to starting the update processing. This prevents the error<br>
condition that we are discussing here, but unfortunately it also results<br>
in a couple of merge dialogs for the modified methods, so the update still<br>
requires manual intervention.<br>
<br>
Dave<br>
<div class="HOEnZb"><div class="h5"><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 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 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 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>