Bad news I'm afraid.  Found a serious bug in the final release candidate.

To reproduce, start up Squeak4.5-13680.image, download the current version
of Collections to the package-cache (Collections-ul.564.mcz), and load it
from the package-cache.  There's an infinite recursion apparently due to
WriteStream>>nextPutAll: being not understood (!!).  For some reason the
load decides to remove nextPutAll:.  Here's part of the stack:

0x142d5508 s WriteStream(Object)>doesNotUnderstand: nextPutAll:
0x142ed7e4 s WriteStream>nextPutAll:
0x142ed840 s ByteSymbol(Symbol)>storeOn:
0x142ed89c s [] in ByteSymbol(Object)>storeString
0x142ed8f8 s String class(SequenceableCollection class)>new:streamContents:
0x142ed954 s String class(SequenceableCollection class)>streamContents:
0x142d5378 s ByteSymbol(Object)>storeString
0x142ed9b0 s SmalltalkImage>event:
0x142eda0c s [] in WeakMessageSend>valueWithArguments:otherwise:
0x142d5300 s WeakMessageSend>withEnsuredReceiverAndArgumentsDo:otherwise:
0x142d5288 s WeakMessageSend>valueWithArguments:otherwise:
0x142d520c s [] in
WeakActionSequenceTrappingErrors>valueWithArguments:startingFrom:
0x142d5564 s BlockClosure>on:do:
0x142d512c s
WeakActionSequenceTrappingErrors>valueWithArguments:startingFrom:
0x142ed3f4 s WeakActionSequenceTrappingErrors>valueWithArguments:
0x142ed450 s SystemEventManager(Object)>triggerEvent:withArguments:
0x142ed4ac s SystemEventManager(Object)>triggerEvent:with:
0x142ed508 s RemovedEvent(AbstractEvent)>trigger:
0x142ed564 s SystemChangeNotifier>trigger:
0x142ed5c0 s SystemChangeNotifier>methodRemoved:selector:inProtocol:class:
0x142d4e7c s Stream class(ClassDescription)>removeSelector:
0x142d4ed8 s MCMethodDefinition>removeSelector:fromClass:
0x142ecf28 s MCMethodDefinition>unload
0x142ecf84 s [] in MCPackageLoader>basicLoad
0x142ecfe0 s OrderedCollection>do:
0x142cc7ec s [] in MCPackageLoader>basicLoad
0x142ed03c s [] in MorphicUIManager>displayProgress:at:from:to:during:
0x142d56d0 s BlockClosure>on:do:
0x142cc6e0 s [] in MorphicUIManager>displayProgress:at:from:to:during:
0x142ed098 s BlockClosure>ensure:
0x142cc64c s MorphicUIManager>displayProgress:at:from:to:during:
0x142cc430 s ProgressInitiationException>defaultResumeValue
0x142cc3d4 s ProgressInitiationException(Exception)>resume
0x142ec780 s ProgressInitiationException>defaultAction
0x142ec7dc s UndefinedObject>handleSignal:
0x142ec838 s MethodContext(ContextPart)>handleSignal:
0x142ec894 s MethodContext(ContextPart)>handleSignal:
0x142ec8f0 s MethodContext(ContextPart)>handleSignal:
0x142cc31c s ProgressInitiationException(Exception)>signal
0x142cc378 s ProgressInitiationException>display:at:from:to:during:
0x142ec94c s ProgressInitiationException class>display:at:from:to:during:
0x142ec9a8 s ByteString(String)>displayProgressAt:from:to:during:
0x142eca04 s ByteString(String)>displayProgressFrom:to:during:
0x142cc1f0 s [] in MCPackageLoader>basicLoad
0x142cc24c s BlockClosure>on:do:
0x142cc168 s [] in MCPackageLoader>basicLoad
0x142cc10c s BlockClosure>on:do:
0x142cc098 s CurrentReadOnlySourceFiles class>cacheDuring:
0x142cc01c s [] in MCPackageLoader>basicLoad
0x142ec3ec s BlockClosure>ensure:
0x142cbf94 s [] in MCPackageLoader>basicLoad
0x142ec448 s BlockClosure>ensure:
0x142cbf20 s RecentMessages>suspendWhile:
0x142cbeac s MCPackageLoader>basicLoad
0x142ec4a4 s [] in MCPackageLoader>loadWithNameLike:
0x142ec500 s BlockClosure>ensure:
0x142cbcf0 s MCPackageLoader>useChangeSetNamed:during:
0x142ec55c s MCPackageLoader>useNewChangeSetNamedLike:during:
0x142cb6ec s MCPackageLoader>loadWithNameLike:
0x14200910 s MCVersionLoader>load
0x1420096c s MCVersionLoader class>loadVersion:
0x142009c8 s MCVersion>load

The 0x142d4ed8 s MCMethodDefinition>removeSelector:fromClass: activation is
indeed trying to unload Stream>>nextPutAll:, but why?

I don't have much time to investigate over the weekend but someone else
with more Monticello smarts may figure this out..

BTW, it may be related to hashing.  When I try the same thing in a
Spur-ised Squeak4.5-13680.image (where I'm loading a patched version of
Collections-ul.564.mcz to restore source to the changed methods in
Character that have no source after the bootstrap) it locks up at a similar
point but die to a deadlock in preference access.  So I suspect that
there's some instability in Monticello loading that's affected by the
different identityHashes obtained in Spur and SqueakV3.

I had hoped to use the release candidate on Spur before using it on
SqueakV3 but hit this bug.  Hubris :-(   ... ;-)

On Thu, Feb 20, 2014 at 10:59 AM, Chris Muller <asqueaker at gmail.com> wrote:

> http://ftp.squeak.org/4.5alpha/Squeak4.5-13680.zip
>
> Changes since 13675:
>
> - Fix cloning MessageSet's.
> - Pointer-chaser, display the id-hash of Morph's in the path to chased
> object.
> - Sending basicNew to CompiledMethod may crash the VM, so don't do that.
> - Fix incorrect display of underscore and caret in case of WideString
> displayed in DejaVu sans Strike fonts.
>

-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140301/fa215cfb/attachment.htm