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@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.