Destructors are useless?

[Michi Henning]

I've been having problem with destructors in the context of having ported C# code
developed under .NET to Mono. What happens is that, on a dual-CPU machine, various
parts of the code crash randomly (and rarely). This always happens during
process shutdown, after some thread has called System.Environm ent.Exit(). Clearly,
some sort of race condition.

Note that what follows only applies to destructors that are called when the process
shuts down -- there is no problem with destructors that get called by the GC when
the process is executing normally.

After a lot of debugging, I tracked it down to a destructor along the following
lines:

~SomeClass
{
if (!_destroyed)
{
System.Console. Error.WriteLine ("Forgot to destroy SomeClass");
}
}

Under Mono, the attempt to write to the console crashes the process because, by the time
destructor is called by the garbage collector, the I/O subsystem has been partially
garbage collected already, and the process dies with a NullPointerExce ption somewhere
in the guts of the I/O subsystem.

Not a problem with .NET: in .NET, the console isn't destroyed until after everything
else is destroyed. (For details, see:
http://www.bluebytesoftware.com/blog...3-20c06ae539ae
There is a comment about two-thirds of the way down the page by Brian Grunkemeyer to that effect.)

Except that I can't rely on this because, as far as I can see, the spec doesn't guarantee that
the console will hang around during process shutdown, so it's not portable code.

Then I started reading the spec a bit more and found that destruction order is not guaranteed and
that, if A refers to B, it's entirely possible for B to be finalized before A. So, that got me to
thinking about what is actually legal to do from within a destructor, if that destructor may be
called during process shutdown. Here is a list of things that are *not* legal to do:

- I cannot dereference anything. If I do, the memory for the object that is reference is guaranteed
to still be there. However, that object may have been finalized already and, as a result, may no
long be in working order if I call a method on it.

- I cannot call a static method on anything. The static method itself is guaranteed to be there. However, the
implementation of the static method may depend on another static object that has been finalized already.
See previous point.

- I cannot safely invoke a virtual method on my own object. That's because my own object may have a derived
part, and that derived part may have been finalized already, and the virtual method may end up using
something in the derived part that conceptually no longer exists.

So, that doesn't leave a lot I can do in a destructor, as far as I can see. Here is what I can do safely:

I can assign or read any of my own data members, and any of the accessible data members of my base class.
That's about it.

So, I can assign null to all my data members that have reference type, just to be nice to the GC. But that
really isn't all that essential in most circumstances.

I can read my own data members. To what purpose? Well, to assert that my program state is still in fine
shape, of course:

~SomeClass()
{
System.Diagnost ics.Assert(_myM ember != null);
System.Diagnost ics.Assert(_myO therMember == null);
}

Oops. I can't safely call a static method, because whatever the implementation of the static method uses may
have been finalized already. Just as I can't safely write to the console, I can't safely assert either.

Of course, I have no real control over when destructors are called. In particular, I have not control
over what destructors run when some thread calls Exit(). As a result, these restrictions apply to *all*
destructors, not just those of static objects.

Hmmm... That leaves destructors completely useless. There is nothing, not even asserting, that I can do safely.
Of course, that begs the question: why have destructors when I can't do anything with them? As far as I can
see, the only legal statements inside a destructor are effectively no-ops.
Mystified,

Michi.

[Dmytro Lapshyn [MVP]]

It is recommended to avoid using finalizers (they are actually called
'finalizers', not 'desctructors') wherever possible. If you need to release
unmanaged resources, implement IDisposable and follow the IDisposable
implementation design pattern recommended by Microsoft. If your class does
not use anything to be disposed, do not use the finalizer at all.

Still, you can put the finalizer to a good use implementing the Microsoft's
disposable object design pattern. In the pattern, the finalizer is the last
chance to release managed resources owned by the instance.

--
Sincerely,
Dmytro Lapshyn [Visual Developer - Visual C# MVP]
"Michi Henning" <mi***@zeroc.co m> wrote in message
news:On******** ******@tk2msftn gp13.phx.gbl...

I've been having problem with destructors in the context of having ported
C# code
developed under .NET to Mono. What happens is that, on a dual-CPU machine,
various
parts of the code crash randomly (and rarely). This always happens during
process shutdown, after some thread has called System.Environm ent.Exit().
Clearly,
some sort of race condition.

Note that what follows only applies to destructors that are called when
the process
shuts down -- there is no problem with destructors that get called by the
GC when
the process is executing normally.

After a lot of debugging, I tracked it down to a destructor along the
following
lines:

~SomeClass
{
if (!_destroyed)
{
System.Console. Error.WriteLine ("Forgot to destroy SomeClass");
}
}

Under Mono, the attempt to write to the console crashes the process
because, by the time
destructor is called by the garbage collector, the I/O subsystem has been
partially
garbage collected already, and the process dies with a
NullPointerExce ption somewhere
in the guts of the I/O subsystem.

Not a problem with .NET: in .NET, the console isn't destroyed until after
everything
else is destroyed. (For details, see:
http://www.bluebytesoftware.com/blog...3-20c06ae539ae
There is a comment about two-thirds of the way down the page by Brian
Grunkemeyer to that effect.)

Except that I can't rely on this because, as far as I can see, the spec
doesn't guarantee that
the console will hang around during process shutdown, so it's not portable
code.

Then I started reading the spec a bit more and found that destruction
order is not guaranteed and
that, if A refers to B, it's entirely possible for B to be finalized
before A. So, that got me to
thinking about what is actually legal to do from within a destructor, if
that destructor may be
called during process shutdown. Here is a list of things that are *not*
legal to do:

- I cannot dereference anything. If I do, the memory for the object that
is reference is guaranteed
to still be there. However, that object may have been finalized already
and, as a result, may no
long be in working order if I call a method on it.

- I cannot call a static method on anything. The static method itself is
guaranteed to be there. However, the
implementation of the static method may depend on another static object
that has been finalized already.
See previous point.

- I cannot safely invoke a virtual method on my own object. That's because
my own object may have a derived
part, and that derived part may have been finalized already, and the
virtual method may end up using
something in the derived part that conceptually no longer exists.

So, that doesn't leave a lot I can do in a destructor, as far as I can
see. Here is what I can do safely:

I can assign or read any of my own data members, and any of the accessible
data members of my base class.
That's about it.

So, I can assign null to all my data members that have reference type,
just to be nice to the GC. But that
really isn't all that essential in most circumstances.

I can read my own data members. To what purpose? Well, to assert that my
program state is still in fine
shape, of course:

~SomeClass()
{
System.Diagnost ics.Assert(_myM ember != null);
System.Diagnost ics.Assert(_myO therMember == null);
}

Oops. I can't safely call a static method, because whatever the
implementation of the static method uses may
have been finalized already. Just as I can't safely write to the console,
I can't safely assert either.

Of course, I have no real control over when destructors are called. In
particular, I have not control
over what destructors run when some thread calls Exit(). As a result,
these restrictions apply to *all*
destructors, not just those of static objects.

Hmmm... That leaves destructors completely useless. There is nothing, not
even asserting, that I can do safely.
Of course, that begs the question: why have destructors when I can't do
anything with them? As far as I can
see, the only legal statements inside a destructor are effectively no-ops.
Mystified,

Michi.

[Tom Porterfield]

On Wed, 27 Apr 2005 17:40:26 +1000, Michi Henning wrote:

Hmmm... That leaves destructors completely useless. There is nothing, not even asserting, that I can do safely.
Of course, that begs the question: why have destructors when I can't do anything with them? As far as I can
see, the only legal statements inside a destructor are effectively no-ops.

If you are writing all managed code, then this statement is essentially it.
Within a pure managed environment this is no need to write a destructor.
Destructors are useful for releasing unmanaged resources. The garbage
collector has no specific knowledge on how to clean up an unmanaged
resource. Your class that encapsulates an unmanaged resource does have
that knowledge. So in your destructor you would take the responsibility
for making sure any unmanaged resources are properly released. Let the GC
handle your managed resources.

Also note that adding a destructor unnecessarily to an object can have a
negative impact on performance. An object with a destructor requires at
least two garbage collections. When the GC runs it reclaims the memory for
inaccessible objects without destructors. It cannot, at that time, collect
the inaccessible objects that do have destructors. Instead it places them
in a list of objects that are marked as ready for finalization. It then
calls the finalize method (destructor) on the objects in that list and then
removes them from the list. The next time GC runs it can them collect
these objects as they are now no longer in the list of objects that are
ready for finalization. So the fact that you have added a destructor to
your object only increases the chances that it will hang around longer than
other objects.
--
Tom Porterfield

[Helge Jensen]

Tom Porterfield wrote:

On Wed, 27 Apr 2005 17:40:26 +1000, Michi Henning wrote: If you are writing all managed code, then this statement is essentially it.
Well,... not quite, but perhaps that why you write "essentiall y"?
Within a pure managed environment this is no need to write a destructor.

Destructors can be quite usefull for checking that appropriate action
has been done on objects. For example you can check whether Dispose()
has been called.

The really usefull information: who forgot to call Dispose, is of course
not available, but I have a nice MixIn class that I can use to record
the stacktrace when the object is created and that is definatly also
usefull to know. It gives you a place to start looking.

While you may not be able to do much with the knowledge in your
finalizer, you can certainly throw an exception (the program *IS*
broken,... it forgot to call Dispose()) and the runtime may do
"good-things" with it. In debug mode the Visual IDE pops up a
messagebox, alerting you to a bug which would otherwise go unnoticed.

You can have your Dispose() call "GC.SuppressFin alize(this)" and avoid
invocation of the destructor.

--
Helge Jensen
mailto:he****** ****@slog.dk
sip:he********* *@slog.dk
-=> Sebastian cover-music: http://ungdomshus.nu <=-

[Michi Henning]

"Tom Porterfield" <tp******@mvps. org> wrote in message
news:7t******** ******@tpporter mvps.org...

On Wed, 27 Apr 2005 17:40:26 +1000, Michi Henning wrote:

Hmmm... That leaves destructors completely useless. There is nothing, not even asserting, that I can do safely. Of course, that begs the question: why have destructors when I can't do anything with them? As far as I can see, the only legal statements inside a destructor are effectively no-ops.
If you are writing all managed code, then this statement is essentially it.

Yes, it sure looks like it.
Within a pure managed environment this is no need to write a destructor.
Destructors are useful for releasing unmanaged resources. The garbage
collector has no specific knowledge on how to clean up an unmanaged
resource. Your class that encapsulates an unmanaged resource does have
that knowledge. So in your destructor you would take the responsibility
for making sure any unmanaged resources are properly released. Let the GC
handle your managed resources.

Sure, I understand all that. A destructor can't do anything that relies on
another
object. In other words, a destructor can't dereference anything, and it cannot
even call a static function. Fine, I accept that. So what are destructors good
for?
Releasing unmanaged resources is one thing. (If I can accept that unmanaged
resources may not be released promptly.) But the *one thing* I still would
like to use destructors for is to check whether my program is still in a sane
state. In other words, I'd like to write assertions about my own member
variables. Unfortunately, I can't even do that: if the assertion holds, no
problem;
but, if the assertion fails, the mere act of having it fail is sufficient to
cause
undefined behavior. So, damned if I do, and damned if don't: if I don't assert,
my program has a bug and will go and do undefined things. If I do assert, the
act
of detecting that my program has a bug causes my program to go and do
undefined things. Talk about being caught between a rock and a hard place...

It is interesting that Java doesn't have this problem. On process exit, Java
guarantees
that destructors (or finalizers, if you prefer) will *not* run. This means that
it's perfectly
safe to put assertions into Java finalizers: while the process is alive and
running, the
assertions are checked whenever the GC decides to garbage collect an object.
And, if the process is exiting, destructors don't run at all, meaning that
there are
no issues with respect to destruction order. Of course, that means that
assertions
don't run during process shut down, but at least my process gets to shut down
without crashing.

And, of course, the idea that C# destructors are good for releasing unmanaged
resources seems flawed, too. After all, how many realistic programs are there
that can release unmanged resources without having to enrol the aid of some
other
managed resource? For example, in my particular case, the program crashed
because
of a destructor that looked like this:

class SomeClass
{
~SomeClass()
{
if(_destroyed)
{
_logger.warning ("Forgot to destroy SomeClass");
}
}

private Logger _logger;
}

What I'm suggesting here is that, for realistic programs, chances are pretty
slim
that a destructor can clean up an unmanaged resource without having to ask for
help from some managed object. But, of course, as soon as that is the case,
the destructor cannot be used anymore. I'm left to conclude that destructors
are so useless that I can't even use them to make assertions about my own
member variables, let alone use them to reclaim unmanaged resources.

It truly would seem appropriate to remove destructors from the language
altogether. At least, that way, people wouldn't have their illusions shattered.

Of course, the alternative would be to not run destructors on process shutdown,
like Java does, and the problem would go away...

Cheers,

Michi.

--
Michi Henning Ph: [phone]
ZeroC, Inc. http://www.zeroc.com

[Michi Henning]

"Helge Jensen" <he**********@s log.dk> wrote in message
news:uB******** ******@tk2msftn gp13.phx.gbl...

The really usefull information: who forgot to call Dispose, is of course
not available, but I have a nice MixIn class that I can use to record
the stacktrace when the object is created and that is definatly also
usefull to know. It gives you a place to start looking.

While you may not be able to do much with the knowledge in your
finalizer, you can certainly throw an exception (the program *IS*
broken,... it forgot to call Dispose()) and the runtime may do
"good-things" with it. In debug mode the Visual IDE pops up a
messagebox, alerting you to a bug which would otherwise go unnoticed.

Hmmm... The specification says that, if a destructor throws, the exception
is ignored and execution of that destructor is aborted. Given that you cannot
safely assert in a destructor or write to the console, it seems unlikely that
you could safely record a stack trace: after all, the classes you have to use
to record the stack trace may have long since been finalized. And, if you
can record the stack trace, throwing the exception is useless because that
exception won't go anywhere (that's guaranteed by the spec). Ergo,
destructors are useless during process shutdown. And, because I cannot
control when constructors run, they are useless altogether.

Cheers,

Michi.

--
Michi Henning Ph: [phone]
ZeroC, Inc. http://www.zeroc.com

[Daniel Jin]

> What I'm suggesting here is that, for realistic programs, chances are pretty

slim
that a destructor can clean up an unmanaged resource without having to ask for
help from some managed object. But, of course, as soon as that is the case,
the destructor cannot be used anymore. I'm left to conclude that destructors
are so useless that I can't even use them to make assertions about my own
member variables, let alone use them to reclaim unmanaged resources.
cannot make assertions hardly means can't reclaim unmanaged resources. the
framework itself already showed that realistic programs can free unmanaged
resources with finalizers. your illusion is the problem here, really. doesn't
do what you want it to do only means it's useless to you.

It truly would seem appropriate to remove destructors from the language
altogether. At least, that way, people wouldn't have their illusions shattered.
Of course, the alternative would be to not run destructors on process shutdown,
like Java does, and the problem would go away...

Cheers,

Michi.

--
Michi Henning Ph: [phone]
ZeroC, Inc. http://www.zeroc.com

[Dilip]

Michi Henning wrote:

It is interesting that Java doesn't have this problem. On process exit, Java guarantees
that destructors (or finalizers, if you prefer) will *not* run. This means that it's perfectly
safe to put assertions into Java finalizers: while the process is alive and running, the
assertions are checked whenever the GC decides to garbage collect an object. And, if the process is exiting, destructors don't run at all, meaning that there are
no issues with respect to destruction order. Of course, that means that assertions
don't run during process shut down, but at least my process gets to shut down without crashing.

Ok -- so how about this:

class someclass
{
~someclass()
{
try
{
System.Diagnost ics.Assert(_myM emVar == null);
}
catch(ObjectDis posedException)
{
// you can't do much here anyway
}
}
}

[Helge Jensen]

Michi Henning wrote:

"Helge Jensen" <he**********@s log.dk> wrote in message
Hmmm... The specification says that, if a destructor throws, the exception
is ignored and execution of that destructor is aborted. Given that you cannot
So conforming runtimes should ignore the exception, that way semantics
is preserved.
safely assert in a destructor or write to the console, it seems unlikely that
you could safely record a stack trace: after all, the classes you have to use
It works well in practice, especially in debug mode.
to record the stack trace may have long since been finalized. And, if you
But i still have a trace indicating the stack that allocated the object
that wasn't Dispose'ed, that's a whole lot better than knowing nothing,
or just it's type.
can record the stack trace, throwing the exception is useless because that
exception won't go anywhere (that's guaranteed by the spec). Ergo,
It goes straight into a message-dialog in debug mode. I put the
stack-trace in the exception-message and that gives a really good place
to start bug-hunting.
destructors are useless during process shutdown. And, because I cannot
control when constructors run, they are useless altogether.

Try rereading my posting, i didn't say they were usefull for semantics,
but for finding bugs. For example the places where Dispose() has been
forgotten.

--
Helge Jensen
mailto:he****** ****@slog.dk
sip:he********* *@slog.dk
-=> Sebastian cover-music: http://ungdomshus.nu <=-

[Michi Henning]

"Dilip" <rd*****@lycos. com> wrote in message
news:11******** **************@ l41g2000cwc.goo glegroups.com.. .

Ok -- so how about this:

class someclass
{
~someclass()
{
try
{
System.Diagnost ics.Assert(_myM emVar == null);
}
catch(ObjectDis posedException)
{
// you can't do much here anyway
}
}
}

No, don't think so. Under Mono, the code crashes with a NullPointerExce ption
if the assertion fails somewhere inside the assert. A far as I can see, the
problem
is that, by the time my finalizer runs, stdout and stderr have been closed
already
and further calls to assert crash the process.

Cheers,

Michi.
--
Michi Henning Ph: [phone]
ZeroC, Inc. http://www.zeroc.com