After some investigation I'm pretty convinced that this isn't a problem with become*. What happens is that doing a becomeForward: nil on any class with an instance will cause trouble for pretty obvious reasons; you send said instance a message - any message - and the vm will find no possible method. Then it tries to send #doesNotUnderstand: to the object, finds no possible method and exits because of a recursive doesNotUnderstand.
I was recently writing some tests for becomeForward: because we will present it in a lecture and I noticed after some experimentations that the image was getting really slow. So may be this is related. In my case I trashed the image and reloaded my good (without strange experiences).
For example in an image with the VMMaker stuff installed I did |foo| foo := CArray new. CArray becomeForward: nil. foo and printIt, which obviously sends a message to foo to print. KAboom. The vm error log shows a recursive dNU as expected.
In the particular case of Martin's problem I think we get the second order effect - an obsolete class has an obsolete super class that just happens to be the one nillified and so sending any message to that obsolete class (which means it has an empty methodDict) involves sending to its superclass, which is now nil, and thus the cycle of desperation begins.
Could we do anything to prevent this? I suppose one might do sometinhg demented like making thevm decide that a nil class means 'treat as protoObject' but personally I say the proper response is 'dont do that'. #become: is dangerous. #becomeForward: is just plain idiotic. At least nobody has done #becomeBackward: - so far.
tim
Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Strange OpCodes: BFM: Branch on Full Moon