Today I made the mistake (twice) of developing in the debugger a #printOn: method depending on a not yet defined #name method in the same class. The result is an image completely blocked out, with an infinite recursion trying to print receiver The culprit is Object>>#name, which by default... is the receiver printString (bypassing the #printStringLimitedTo:... version)! So if you implement #printOn: depending on #name, but you didn't implement #name differently to how Object does, you created yourself an infinite recursion. Now I found why it is happening, so I will explicitly define #name prior to any #printOn: implementation. Particularly if I'm inside the debugger which will try to print the offending class or any variable affected by this bug. However I have a few questions about this: a) Shouldn't a recursion too deep be detected? b) Why can't I interrupt a process running in the UI thread like this one? Regards. Esteban A. Maringolo The call stack: DTColumnParameter(Object)>>printOn: DTColumnParameter>>printOn: DTColumnParameter(Object)>>printStringLimitedTo: in Block: [ :s | self printOn: s ] String class(SequenceableCollection class)>>streamContents:limitedTo: DTColumnParameter(Object)>>printStringLimitedTo: DTColumnParameter(Object)>>printString DTColumnParameter(Object)>>name <<---- Here we go... DTColumnParameter>>printOn: DTColumnParameter(Object)>>printStringLimitedTo: in Block: [ :s | self printOn: s ] String class(SequenceableCollection class)>>streamContents:limitedTo: DTColumnParameter(Object)>>printStringLimitedTo: DTColumnParameter(Object)>>printString DTColumnParameter(Object)>>name