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

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Mon Aug 22 16:18:39 UTC 2016


There might be another possibility: destroy the progress bar in the
preamble.
How to detect the progress bar is left as an exercize (translate: I just
don't know, maybe also by walking the stack).
Reopen the progress bar in postscript.

2016-08-22 17:57 GMT+02:00 Chris Muller <asqueaker at gmail.com>:

> This isn't the first time our changes have caused update hiccups.  I
> think it just comes with the territory.  Easiest to just save off
> another image that is beyond the problem and move on from there.
>
> On Mon, Aug 22, 2016 at 7:36 AM, Bert Freudenberg <bert at freudenbergs.de>
> wrote:
> > Seen it, discussed with Marcel but we don't have a good idea yet how to
> work
> > around it.
> >
> > 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?
> >
> > - Bert -
> >
> >
> > On Sun, Aug 21, 2016 at 10:55 PM, 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/squeak-dev/attachments/20160822/0a85490f/attachment.htm


More information about the Squeak-dev mailing list