<div dir="ltr">Experiencing the same issue, and got around it the same way you describe.</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><font size="2" face="arial, helvetica, sans-serif" color="#000000">-Laura Perez Cerrato</font></div></div></div>
<br><div class="gmail_quote">On 21 August 2016 at 17:55, 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 class="HOEnZb"><font color="#888888"><br>
<br>
Levente</font></span><div class="HOEnZb"><div class="h5"><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>