On Monday 12 July 2004 6:42 am, Milan Zimmermann wrote:
> one note/question - when playing with your solution last night I
> thought the "reason" why the save hang was the "improperly renamed class
> ZTime" - do you think it was that or just the fact I had the Changeset
> browser opened in the project, which made the object graph too big and
> Squeak decided to stop the save?)

It's not that the object graph was too big. It's that there was a pointer 
outside the graph that couldn't get resolved properly (in this case, a 
ReadOnlyVariableBinding of #ZTime to the class Time). This was caused 
(indirectly) by your having a ChangeSorter open in the project.

> I tried to look for the "ZTime" class in Browser before I closed the
> "Change Sorter" but did not find it, not sure why. In any case, do you
> think I must have renamed it or something else could have happened to the
> image? - Just curious, I am not aware of renaming any class, perhaps by
> accident .. I have been playing with creating classes from the workspace,
> perhaps I messed up at some point.

The problem existed in a stock image. Read on...

I will explain in detail what I did to explore the problem in hopes that it 
may help some of you. This is in the "teaching people to fish" spirit.

[For those of you who want to play along at home, you may repeat this problem 
using a stock 3.7g image by making a new Morphic project, opening a 
ChangeSorter in it, and trying to save the project on disk]

- First, I noticed that the project stopped saving at some point and the world 
would respond to mouse clicks again (that is, I could raise a menu).

- I then returned to the parent project (the one I had asked to save) and saw 
an inform dialog that said "extra associations".

- I opened a Workspace, typed in the phrase "extra associations", and hit 
alt-shift-E (search for methods containing the string in a string literal). 
Actually, I could have done this easier by shift-clicking on the string in 
the informer, and hitting alt-shift-E, but I knew I'd need a Workspace 
anyway.

- I found ImageSegment>>prepareToBeSaved. Looking down at the bottom of this 
method, I saw that it was trying to (but didn't) open an inspector. So...

- In my Workspace, I typed in 
	ImageSegment allInstances
and hit alt-shift-I (explore it). I saw that there was one of them.

- I selected this one in the explorer, and typed in
	self prepareToBeSaved
in the bottom of the explorer, and hit alt-D (do it).

- Again I saw the inform dialog, but this time when I hit the OK button I saw 
the inspector pop up. It contained an IdentitySet with one element (which 
printed itself as #ZTime).

- I typed in to the bottom of the dialog
	self anyOne inspect

- This brought up an Inspector on a ReadOnlyVariableBinding whose key was 
#ZTime and whose value was Time

- selecting the key (#ZTime) in the inspector's upper left hand pane, I 
brought up the context menu using the mouse. I chose "objects pointing to 
this value"

[A much better tool for tracing pointers is Avi Bryant's Pointer Explorer, 
available using SqueakMap. I rarely have much success using the "chase 
pointers" choice (the Pointer Finder).].

- I got an inspector on an array with five slots. The last slot was an 
ObjectExplorerWrapper (a side effect of having the other explorer open). But 
the other four were interesting. They were:

	- a big array with symbols and other things in it: #(#EventPollFrequency 
#startUpWithCaption:at:allowKeyboard: #delayedBy: #anchors #panForTrack: nil 
#'read/write segment' #reciprocalFloorLog: an Object an Object #radial 
#packageNamed:ifAbsent: an Object #blockAssociationCheck: an Object an 
Object ...
	- a ClassChangeRecord
	- #ZTime->a ClassChangeRecord
	- another big array: #(Array Project nil a Project(NewChanges) false 
PasteUpMorph TranscriptStream ChangeSet Form HandMorph a StringMorph(2714)'a 
StringMorph(113)''a PasteUpMorph(1263) [world] that was not counted'' that 
was not counted' a StringMorph(3918)'a StringMorph(1420)''a 
SimpleHierarchicalListMorph(1810) that was not counted'' ...

- I guessed that the two big arrays were used by the ImageSegment, so focused 
on the ClassChangeRecords.

- Now, I knew that ClassChangeRecords lived in ChangeSets, which are pointed 
to by ChangeSorters. Having seen a ChangeSorter in your project, I suspected 
that was the problem. So I selected the association (#ZTime->a 
ClassChangeRecord) and chose from the Inspector context menu "objects 
pointing to it". I saw:

#(#Time->a ClassChangeRecord #TimeStamp->a ClassChangeRecord #ZTime->a 
ClassChangeRecord nil nil nil nil #Date->a ClassChangeRecord nil #ZDate->a 
ClassChangeRecord nil #ZTimeStamp->a ClassChangeRecord)

- "Ah, I see" I said to myself. Now I recalled that we renamed some classes in 
the Great Time And Date Revolution around CS 5660. So I did "objects pointing 
to it" another two times until I got to
	a ChangeSet named 5668Chrnl-i-CnvtTDateTTime1

- So now my suspicion that the ChangeSorter was involved was proved. I knew 
how ChangeSorters and ChangeSets were structured, but following the pointers 
further would have led to a ChangeSetCategory and/or the ChangeSorter.

- But the question about why was this one class an unresolved out pointer 
still remained.

The answer was here in ImageSegment>>prepareToBeSaved:

		(Smalltalk associationAt: assoc key ifAbsent: [3]) == assoc ifTrue: [
			outPointers at: (outIndexes at: assoc) put: 
				(DiskProxy global: #Smalltalk selector: #associationAt: 
					args: (Array with: assoc key)).

In other words, since Smalltalk didn't contain #ZTime (this was a temporary 
rename), we didn't replace the association with a DiskProxy.

In the Workspace, you can see other potential problems like this by doing a 
print-it or inspect-it on:

ReadOnlyVariableBinding allInstances
	select: [ :ea | ea value isBehavior and: [ (Smalltalk at: ea key ifAbsent: 
[]) ~~ ea value ]]
	thenCollect: [ :ea | ea key -> ea value ]

which returns:

#(#CRGestureProcessor->AnObsoleteCRGestureProcessor 
#PseudoClassOrganizer->AnObsoletePseudoClassOrganizer 
#CRDictionary->AnObsoleteCRDictionary 
#ClassOrganizer->AnObsoleteClassOrganizer #ZDate->Date 
#CRAddFeatureMorph->AnObsoleteCRAddFeatureMorph 
#CRLookupItem->AnObsoleteCRLookupItem #ZTime->Time 
#IRCProtocolMessage->AnObsoleteIRCProtocolMessage 
#IRCMorph->AnObsoleteIRCMorph #SMTPSocket->AnObsoleteSMTPSocket 
#CRDisplayProperties->AnObsoleteCRDisplayProperties)

But this begs the question of "why did it appear in the out pointers?". If you 
look at ChangeSet>>objectForDataStream: you will see that ChangeSets 
themselves don't get stored. So something else must have been responsible. 
What? Hmm...

Let's look at who might be pointing to it. We can skip ChangeRecords, since 
they won't get stored. So let's try this:


| zt ptrs baddies ptrs2 |
Smalltalk garbageCollect.
zt := (ReadOnlyVariableBinding allInstances select: [ :ea | ea key = #ZTime ]) 
first.
ptrs := Smalltalk pointersTo: zt except: { zt. zt key. zt value. }.
baddies := OrderedCollection new.
ptrs do: [ :p |
	ptrs2 := nil.
	ptrs2 := Smalltalk pointersTo: p except: { ptrs. p. thisContext. thisContext 
sender. thisContext home. thisContext blockHome. zt. zt key. zt value. 
baddies. baddies collector }.
	ptrs2 := ptrs2 reject: [ :ea |
		('*ChangeRecord*' match: ea class name) ].
	ptrs2 isEmpty ifFalse: [baddies addAll: ptrs2 ].
].
baddies asArray inspect.


Which shows me a single MethodContext, whose receiver is Delay, and whose 
source is missing. But looking around the context, I see that there is a temp 
of a Semaphore, and on its list is a process with priority 80.

Opening a Process browser, I see that that's the timer interrupt watcher. 
Apparently this didn't get recompiled and restarted, or it's the old method.

By printing the result of

	Delay class compiledMethodAt: #timerInterruptWatcher

I see that the method is different (different identityHash).

OK... let's try to fix the problem. Looks like I'll have to restart the timer 
interrupt watcher, but I don't want to kill off the existing delays.

Reading the code of Delay class shows how this might work.

Let's try:

	Delay shutDown; startTimerInterruptWatcher; startUp.

Repeating the search for baddies above shows that that one reference has been 
removed.

Trying the project storage (with a change sorter) again now works.

Was that fun, or what?

Why did I say that the class was "improperly renamed"? Notice that all of the 
other associations besides #ZTime and #ZDate refer to classes whose names 
start with "AnObsolete" and which will in fact report that they are obsolete 
when asked.

However, #ZTime and #ZDate actually point to live classes with other names!

How did this happen? Well, in the postscript of change set 
5668Chrnl-i-CnvtTDateTTime1 there is the following code:

| jdn |
jdn _ SystemVersion current date asDate julianDayNumber.

#(#Date #Time #TimeStamp) 	
	do: 	[ :s | | zname tname |
		Transcript show: (Smalltalk at: s) allInstances; cr.
		zname  _ ('Z', s) asSymbol.
		tname  _ ('T', s) asSymbol.
		(Smalltalk at: s) rename: zname.
		(Smalltalk at: tname) rename: s.
		(Smalltalk systemNavigation allCallsOn: (Smalltalk associationAt: zname))
			do: [ :ref | ref actualClass ifNotNilDo: [ :ac | ac recompile: ref 
methodSymbol ] ].
		Smalltalk forgetClass: (Smalltalk at: zname) logged: false.
		Transcript show: 'replaced ', s; cr ].

Transcript show: 'removing subclasses....'.
(Magnitude subclasses select: [ :sc | sc name beginsWith: 'Z' ]) 
	do:  [ :sc | Magnitude  removeSubclass: sc ].
Transcript tab; show: 'removed.'; cr.


That is (for instance, for #ZTime):

* There used to be a subclass of Magnitude called Time.
* we defined a new class called TTime
* we renamed Time to ZTime
* we renamed TTime to Time
* we then recompiled all the references to the old versions of Time (which was 
now named #ZTime)
* we then forgot #ZTime, and tried not to remember that we had done so (in the 
change set) 
* then we tried to remove #ZTime (again) using #removeSubclass: (this 
shouldn't have been necessary after #forgetClass:logged:, and is almost 
always the wrong thing to do from outside the guts of the system).

However, this didn't work entirely right. First, what we *should* have done 
instead of #forgetClass:logged: and #removeSubclass: was instead

	(Smalltalk at: zname) removeFromSystem: false.


Anyway, this is probably more than you wanted to know.

I'll post a change set that fixes this problem, so saving projects that 
contain change sorters will work.

Have fun,
-- 
Ned Konz
http://bike-nomad.com/squeak/