<div dir="ltr"><div>Seen it, discussed with Marcel but we don't have a good idea yet how to work around it.</div><div><br></div><div>The only thing I can think of is to walk up the sender chain and restart some context above the one referencing the old instance layout. Maybe an exception handler in the updater that restarts updating in this specific case?</div><div><br></div><div>- Bert -</div><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Aug 21, 2016 at 10:55 PM, Levente Uzonyi <span dir="ltr"><<a href="mailto:leves@caesar.elte.hu" target="_blank">leves@caesar.elte.hu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Same here. I think the code changes during the update and the old code on the stack causes the problem.<span><font color="#888888"><br>
<br>
Levente</font></span><div><div><br>
<br>
On Sun, 21 Aug 2016, Chris Muller wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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" target="_blank">lewis@mail.msen.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Moving from vm-dev to squeak-dev because it is a trunk update stream 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 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>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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 you<br>
see how many blocks we traverse just to change display of a bar...), then<br>
the old block has invalid inst var offsets (offsets to the old object that<br>
now has become a new object with new layout).<br>
<br>
In an interactive image, just close the debugger and relaunch the update.<br>
In an headless automated process, well... We should have fixed the 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" target="_blank">tim@rowledge.org</a>>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I just tried running the vmmaker-build script on my iMac with weirdly bad<br>
results.<br>
<br>
The vm it downloads is the CogSpur.app-16.18.3692 version. Whilst 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. For<br>
example in a progress bar update (which I can???t provide a log for 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 bars. A<br>
similar but not identical problem happened during another attempt.<br>
<br>
Attempting to filein the BuildSqueakSpurTrunkVMMaker.st file failed 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 to<br>
date 5.1rc1 image. Which has sorta-worked, in a rather odd manner. It got<br>
to the final save and quit but when I start the supposedly prepared image<br>
there is a problem with it trying to filein that file. I can???t tell right<br>
now if it relates to the manual filein I started or if something got added<br>
as a deferred action? Or maybe it???s a side-effect of the filein 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>
</blockquote></blockquote>
<br>
</blockquote>
<br>
</blockquote>
</div></div></blockquote></div><br></div></div>