Cannot update due to LRUCache

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Cannot update due to LRUCache

Chris Muller-3
Shape-change of LRUCache causes EE during update.  Quick glance shows it's used by the blasted progress bar!



Reply | Threaded
Open this post in threaded view
|

Re: Cannot update due to LRUCache

Chris Muller-3
During update, ScrollBar class>>#arrowOfDirection:size:color: was called which has a "ArrowImagesCache" class-var which is a LRUCache..


Reply | Threaded
Open this post in threaded view
|

Re: Cannot update due to LRUCache

David T. Lewis
In reply to this post by Chris Muller-3
On Sun, Dec 15, 2013 at 05:20:11PM -0600, Chris Muller wrote:
> Shape-change of LRUCache causes EE during update.  Quick glance shows it's
> used by the blasted progress bar!

And the EE actually worked? Even after I fixed it? Excellent!  :-)

Dave


Reply | Threaded
Open this post in threaded view
|

Re: Cannot update due to LRUCache

Levente Uzonyi-2
In reply to this post by Chris Muller-3
I've seen this error once, but couldn't reproduce it anymore. The reason
why it happens, is that the update process doesn't evaluate the
postscript when it has to. It loads Collections-ul.546, then loads
Collections-ul.547 without evaluating the postscript of
Collections-ul.546, even though there's an update map which should ensure
that. After updating Collections to the latest version, it tries to
evaluate the postscript, but it's too late at that point.


Levente

On Sun, 15 Dec 2013, Chris Muller wrote:

> During update, ScrollBar class>>#arrowOfDirection:size:color: was called which has a "ArrowImagesCache" class-var which is a LRUCache..
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Cannot update due to LRUCache

Chris Muller-3
It seems to happen every time using the latest alpha image (at ftp.squeak.org/4.5-alpha).


On Mon, Dec 16, 2013 at 2:39 AM, Levente Uzonyi <[hidden email]> wrote:
I've seen this error once, but couldn't reproduce it anymore. The reason why it happens, is that the update process doesn't evaluate the postscript when it has to. It loads Collections-ul.546, then loads Collections-ul.547 without evaluating the postscript of
Collections-ul.546, even though there's an update map which should ensure that. After updating Collections to the latest version, it tries to evaluate the postscript, but it's too late at that point.


Levente


On Sun, 15 Dec 2013, Chris Muller wrote:

During update, ScrollBar class>>#arrowOfDirection:size:color: was called which has a "ArrowImagesCache" class-var which is a LRUCache..






Reply | Threaded
Open this post in threaded view
|

Re: Cannot update due to LRUCache

Nicolas Cellier
Hmm, what if a mcm map was pointing to a version that was removed from trunk?
I understand that the update for this map would abort due to a premature
^count in MCConfiguraiton>>depsSatisfying:versionDo:displayingProgress:

It seems that several maps are broken (point to absent version)
update-fbs.244 being the first I detected, but there must be some others...


2013/12/16 Chris Muller <[hidden email]>
It seems to happen every time using the latest alpha image (at ftp.squeak.org/4.5-alpha).


On Mon, Dec 16, 2013 at 2:39 AM, Levente Uzonyi <[hidden email]> wrote:
I've seen this error once, but couldn't reproduce it anymore. The reason why it happens, is that the update process doesn't evaluate the postscript when it has to. It loads Collections-ul.546, then loads Collections-ul.547 without evaluating the postscript of
Collections-ul.546, even though there's an update map which should ensure that. After updating Collections to the latest version, it tries to evaluate the postscript, but it's too late at that point.


Levente


On Sun, 15 Dec 2013, Chris Muller wrote:

During update, ScrollBar class>>#arrowOfDirection:size:color: was called which has a "ArrowImagesCache" class-var which is a LRUCache..










Reply | Threaded
Open this post in threaded view
|

Re: Cannot update due to LRUCache

Chris Muller-3
Did you fix it?  Since you identified a problem with update-fbs.244 it would help if you would at least tell us what it is rather than requiring another resource go off and re-detect what you already detected.


On Mon, Dec 16, 2013 at 4:20 PM, Nicolas Cellier <[hidden email]> wrote:
Hmm, what if a mcm map was pointing to a version that was removed from trunk?
I understand that the update for this map would abort due to a premature
^count in MCConfiguraiton>>depsSatisfying:versionDo:displayingProgress:

It seems that several maps are broken (point to absent version)
update-fbs.244 being the first I detected, but there must be some others...


2013/12/16 Chris Muller <[hidden email]>
It seems to happen every time using the latest alpha image (at ftp.squeak.org/4.5-alpha).


On Mon, Dec 16, 2013 at 2:39 AM, Levente Uzonyi <[hidden email]> wrote:
I've seen this error once, but couldn't reproduce it anymore. The reason why it happens, is that the update process doesn't evaluate the postscript when it has to. It loads Collections-ul.546, then loads Collections-ul.547 without evaluating the postscript of
Collections-ul.546, even though there's an update map which should ensure that. After updating Collections to the latest version, it tries to evaluate the postscript, but it's too late at that point.


Levente


On Sun, 15 Dec 2013, Chris Muller wrote:

During update, ScrollBar class>>#arrowOfDirection:size:color: was called which has a "ArrowImagesCache" class-var which is a LRUCache..














Reply | Threaded
Open this post in threaded view
|

Re: Cannot update due to LRUCache

Nicolas Cellier
No, I only discovered a problem with updates 244->246 and fixed it by uploading the missing package.
But since the latests updates were redone one or more times, and since some packages did disappear, it might well have been a temporary problem.

To be sure, I ran some small dumb and naive utility (attached) from a 4.4 image
MCMcmUpdater checkAllUpdates: #('http://source.squeak.org/trunk').
and detected olny those problems (very long to run):

update-fbs.241.mcm
(45Deprecated-fbs.8) has different id in (http://source.squeak.org/trunk)
update-fbs.243.mcm
(Tests-fbs.240) has different id in (http://source.squeak.org/trunk)

Those two packages had two different versions posted, and some update points to the wrong UUID (the previous version that were replaced).
Fortunately (???) the mcm updater does not check the ids, so this does not perturb the update process...

I also detected some false alarms:

update-cwp.217.mcm
(VersionNumber-cmm.4) not found in (http://source.squeak.org/trunk)
(XML-Parser-ael.35) not found in (http://source.squeak.org/trunk)
(ReleaseBuilder-cmm.76) not found in (http://source.squeak.org/trunk)
(ShoutCore-fbs.35) not found in (http://source.squeak.org/trunk)
(VersionNumberTests-nice.3) not found in (http://source.squeak.org/trunk)
(HelpSystem-Core-ul.55) not found in (http://source.squeak.org/trunk)
(HelpSystem-Tests-ul.14) not found in (http://source.squeak.org/trunk)
(Help-Squeak-Project-cmm.9) not found in (http://source.squeak.org/trunk)
(Help-Squeak-TerseGuide-dtl.2) not found in (http://source.squeak.org/trunk)
update-cwp.237.mcm
(Environments-cwp.28) not found in (http://source.squeak.org/trunk)
update-fbs.244.mcm
(MorphicExtras-fbs.118) not found in (http://source.squeak.org/trunk)
(MorphicTests-fbs.22) not found in (http://source.squeak.org/trunk)
(MorphicExtrasTests-fbs.2) not found in (http://source.squeak.org/trunk)
(MultilingualTests-ul.15) not found in (http://source.squeak.org/trunk)
(Nebraska-ul.35) not found in (http://source.squeak.org/trunk)
(NetworkTests-fbs.36) not found in (http://source.squeak.org/trunk)
(PreferenceBrowser-bf.47) not found in (http://source.squeak.org/trunk)
(Protocols-fbs.42) not found in (http://source.squeak.org/trunk)

For the false alarms, I suspect the server sometimes runs out of file id - that also happens from time to time in my image, the symptom being a .changes file not found error (while trying to open a readonly copy).


2013/12/17 Chris Muller <[hidden email]>
Did you fix it?  Since you identified a problem with update-fbs.244 it would help if you would at least tell us what it is rather than requiring another resource go off and re-detect what you already detected.


On Mon, Dec 16, 2013 at 4:20 PM, Nicolas Cellier <[hidden email]> wrote:
Hmm, what if a mcm map was pointing to a version that was removed from trunk?
I understand that the update for this map would abort due to a premature
^count in MCConfiguraiton>>depsSatisfying:versionDo:displayingProgress:

It seems that several maps are broken (point to absent version)
update-fbs.244 being the first I detected, but there must be some others...


2013/12/16 Chris Muller <[hidden email]>
It seems to happen every time using the latest alpha image (at ftp.squeak.org/4.5-alpha).


On Mon, Dec 16, 2013 at 2:39 AM, Levente Uzonyi <[hidden email]> wrote:
I've seen this error once, but couldn't reproduce it anymore. The reason why it happens, is that the update process doesn't evaluate the postscript when it has to. It loads Collections-ul.546, then loads Collections-ul.547 without evaluating the postscript of
Collections-ul.546, even though there's an update map which should ensure that. After updating Collections to the latest version, it tries to evaluate the postscript, but it's too late at that point.


Levente


On Sun, 15 Dec 2013, Chris Muller wrote:

During update, ScrollBar class>>#arrowOfDirection:size:color: was called which has a "ArrowImagesCache" class-var which is a LRUCache..



















MCConfiguration-checkIntegrity.st (1K) Download Attachment
MCMcmUpdater class-checkAllUpdates.st (2K) Download Attachment