How to destroy an object?

Yesterday, when I tried to search for the string 'value' in the 'methods
containng text' window, I discovered a rogue object that refused to
cooperate with the search, killing the process with an ugly terminate
message.  So I began my quest to kill said object  :-) but discovered that
although I know how to create an object, I didn't have a good idea of how to
destroy one.   This object was referred to by a global variable, but I could
not find it by browsing the Smalltalk dictionary.   So, I did not know what
to call it.  I eventually 'killed' the thing by enumerating over it and
using 'become' to tranform it into a string, but this did not seem very
satisfying.  Then again, by converting it to a string, did I really destroy
it?  Yes, my 'search' problem has gone away . . . but . . .

What is the recommended way to 'destroy' an object?  What if you do not know
its key (its variable)?  Did I do the right thing by changing into a string?

Thanks for any insight,

Steve

Steve,

> Yesterday, when I tried to search for the string 'value' in the 'methods
> containng text' window, I discovered a rogue object that refused to
> cooperate with the search, killing the process with an ugly terminate
> message.  So I began my quest to kill said object  :-) but discovered that
> although I know how to create an object, I didn't have a good idea of how
to
> destroy one.   This object was referred to by a global variable, but I
could
> not find it by browsing the Smalltalk dictionary.   So, I did not know
what
> to call it.  I eventually 'killed' the thing by enumerating over it and
> using 'become' to tranform it into a string, but this did not seem very
> satisfying.  Then again, by converting it to a string, did I really
destroy
> it?  Yes, my 'search' problem has gone away . . . but . . .
>
> What is the recommended way to 'destroy' an object?  What if you do not
know
> its key (its variable)?  Did I do the right thing by changing into a
string?

Good question.  You'll find some varying opinions on this topic - I'll give
you the correct answer :)

The #bcome: trick will typically only mask the problem.  It can be helpful
by replacing expensive objects with cheap ones, and might even break cycles
to ultimately let the garbage collector do its magic.  The unpleasant truth
is that you really need to track down the references to such objects, and
"fixing it" with #become: only makes it harder to find the problem, which is
one or more unwanted references to the object - otherwise it would just go
away.  Sometimes the reference might be from a thread (instance of Process)
in some kind of limbo state, or maybe just blocked on a semaphore that's not
getting signalled due to some other problem.  You can look at all instances
of Process, or use Dolphin's built-in process viewer, or the similar goodie
that's on my web site; if you see more than the typical five threads
(main/UI, timing, finalization, idler, undertaker) then this might be the
problem, unless you recognize the extras as threads that you've created.
Zombie views are another common source of problems; you can try the scream
button to close all views (note that you'll want to save any changes to
windows you have open before trying this).

As far as destroying objects in Smalltalk - you don't, the garbage collector
does.  Ok, that's not entirely true.  Read the Object Liberation Strategy
(or whaterver it's called) on the Wiki; it talks about freeing external
resources that might be associated with a Smalltalk object.  Generally the
base system takes care of these things nicely by freeing, (for example) GDI
objects during finalization and on shutdown, just in case finalization
hadn't finished before the image shuts down.  I picked GDI objects as an
example for a reason: on Win9x with its 16 bit graphics kernel and highly
compartmentalized memory, it's fairly easy to starve a machine by doing
complex graphics.  The answer is to explicitly free objects rather than
waiting for finalization to do it. Finalization would work if given time;
the problem is that the app sometimes quits before that can happen.  Unless
you're doing really complicated stuff, you won't run into this, and if you
do, it's easy enough to fix.  However, note that in the case of cleaning up
GDI objects, it's not the Pen, Brush, Region etc. that one destroys, only
the associated GDI object; the wrapper is then harmless and left for the
garbage collector to excise at its convenience.

Does that help?

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"P.S. Neeley" <[hidden email]> wrote in message
news:GZpU6.4726$[hidden email]...
> Yesterday, when I tried to search for the string 'value' in the 'methods
> containng text' window, I discovered a rogue object that refused to
> cooperate with the search, killing the process with an ugly terminate
> message.  So I began my quest to kill said object  :-) but discovered that
> although I know how to create an object, I didn't have a good idea of how
to
> destroy one.   This object was referred to by a global variable, but I
could
> not find it by browsing the Smalltalk dictionary.   So, I did not know
what
> to call it.  I eventually 'killed' the thing by enumerating over it and
> using 'become' to tranform it into a string, but this did not seem very
> satisfying.  Then again, by converting it to a string, did I really
destroy
> it?  Yes, my 'search' problem has gone away . . . but . . .

From: "P.S. Neeley" <[hidden email]>
> Yesterday, when I tried to search for the string 'value' in the 'methods
> containng text' window, I discovered a rogue object that refused to
> cooperate with the search, killing the process with an ugly terminate
> message.  So I began my quest to kill said object  :-) but discovered that
> although I know how to create an object, I didn't have a good idea of how
to
> destroy one.   This object was referred to by a global variable, but I
could
> not find it by browsing the Smalltalk dictionary.   So, I did not know
what
> to call it.  I eventually 'killed' the thing by enumerating over it and
> using 'become' to tranform it into a string, but this did not seem very
> satisfying.  Then again, by converting it to a string, did I really
destroy
> it?  Yes, my 'search' problem has gone away . . . but . . .

If you have hold of the unwanted object you can send it #allReferences.
That's case when you have it in a browser or debugger (you can always
send messages to the temporaries - the top right pane is in scope of the
selected temporary - replace the printString output at the top-righ pane by:
    self allReferences
and inspectIt (right click or Ctrl-I)

If you don't have hold of it, and its class has few instances, you can
inspect:
    UnwantedClass allInstances


hope it helps

Ricardo

Ricardo,

    instead of inspecting allReferences, mostly I use display it because the
inspector generates more references to the target instance.

    We have fixed som scenarios with pathological objects using
>>oneWayBecom: nil,  and letting the garbage collectior do it's magic..

    regards

Sebastian



Ricardo Nogueira <[hidden email]> escribió en el mensaje de noticias
9fugdu$6981p$[hidden email]...
>
> "P.S. Neeley" <[hidden email]> wrote in message
> news:GZpU6.4726$[hidden email]...
> > Yesterday, when I tried to search for the string 'value' in the 'methods
> > containng text' window, I discovered a rogue object that refused to
> > cooperate with the search, killing the process with an ugly terminate
> > message.  So I began my quest to kill said object  :-) but discovered
that
> > although I know how to create an object, I didn't have a good idea of
how that
> > although I know how to create an object, I didn't have a good idea of
how by: