Mantis Bugtracker
  

Viewing Issue Advanced Details Jump to Notes ] View Simple ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0005910 [Squeak] Traits minor always 02-02-07 11:31 04-03-10 19:06
Reporter MAD View Status public  
Assigned To dvf
Priority normal Resolution open Platform
Status assigned   OS
Projection none   OS Version
ETA none Fixed in Version Product Version 3.10
  Product Build
Summary 0005910: Traits-Tests leaves referenced Obsolete Classes in the image
Description I was playing with the test runner and one of the Traits-Tests has
left many Obsolete classes hanging around that I'm unable to remove by
normal means; this means that I'm having problems using the
Refactoring Browser.

In order to track the classes down I followed the hints on
http://wiki.squeak.org/squeak/2631 [^] ; when I got to bringing up the
Pointer Finder it said:

#ProtoObject -> ProtoObject class
subclasses: Array
9: AnObsoleteC3 class

I inspected protoObject and the subclasses array has 105 members, many
of them repeated:

{Object . ObjectOut . ImageSegmentRootStub . MessageCatcher .
DynamicBindingsInfo . MaMinimalObject . MAConditionBuilder .
MAProxyObject . AnObsoleteC3 . AnObsoleteC4 . AnObsoleteC6 .
AnObsoleteC3 . AnObsoleteC4 . AnObsoleteC6 . AnObsoleteC3 .
AnObsoleteC4 . AnObsoleteC6 . AnObsoleteC3 . AnObsoleteC4 .
AnObsoleteC6 . AnObsoleteC3 . AnObsoleteC4 . AnObsoleteC6 .
...etc... }

This didn't look good, so I then did a search through references to
ProtoObject, and found that TraitsResource (in Traits-Tests) looks
like the guilty party - it has three methods
setUpTrivialRequiresFixture, setUpTwoLevelRequiresFixture,
setUpTranslatingRequiresFixture - these include lines like (for C3,
C4, C6):

        self c3: (self
                                createClassNamed: #C3
                                superclass: ProtoObject
                                uses: { }).
        self c3 superclass: nil.

Another run of the Traits-Tests suite left me with yet more of these
obsolete classes. They don't get garbage-collected in the normal course of events.

Todd Blanchard pointed out that the cause is probably due to compiled code:
"This method has been compiled and the reference to class C3 has been
resolved in the compiled code. If the C3 class has gone away - the
class is renamed to AnObsoleteC3. So the code appears to reference
C3, but it really references the obsolete one. You need to recompile
this method - just trivially alter it by adding a space and accept
it. The method will be recompiled. You might want to do a source
code search for C3, then ensure that all those methods get recompiled."

Bert Freudenberg noted that the classes could be forced out by doing:
ProtoObject subclassesDo: [ :sc | sc isObsolete ifTrue: [ProtoObject removeSubclass: sc]].

This does remove the classes, but then RB hangs on AnObsoleteT1 (a Trait)...



Steps To Reproduce
Additional Information 3.10alpha.7068
Attached Files

- Relationships

- Notes
(0009389 - 133 - 133 - 133 - 133 - 133 - 133)
user356
02-02-07 11:41

Note that the issue that causes the RB to attempt to access the Obsolete classes can be fixed by the changeset I've added as bug 5911
 

- Issue History
Date Modified Username Field Change
02-02-07 11:31 user356 New Issue
02-02-07 11:31 user356 Status new => assigned
02-02-07 11:31 user356 Assigned To  => KenCausey
02-02-07 11:41 user356 Note Added: 0009389
02-02-07 23:17 KenCausey Assigned To KenCausey => dvf
02-02-07 23:17 KenCausey Category Any => Traits
04-03-10 19:06 KenCausey Reporter user356 => MAD


Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
53 total queries executed.
33 unique queries executed.
Powered by Mantis Bugtracker