May 13, 2011 Re: The GC, destructors, exceptions and memory corruption | ||||
---|---|---|---|---|
| ||||
Posted in reply to Vladimir Panteleev | Am 13.05.2011 10:33, schrieb Vladimir Panteleev: > On Fri, 13 May 2011 11:22:11 +0300, Daniel Gibson <metalcaedes@gmail.com> wrote: > >> It may be sane to just define that destructors are nothrow and if they throw anyway to terminate the program. >> >> What is the current behaviour anyway? ;) > > D2 throws a FinalizeError (which is an Error, so "not recoverable"). So the program is terminated? In that case you don't really have to worry about the state of the GC, right? > D1 just allows the exception to propagate through the GC to whatever > caused a GC to run. > Both leave the GC in an indeterminate state, as far as I can tell. > |
May 13, 2011 Re: The GC, destructors, exceptions and memory corruption | ||||
---|---|---|---|---|
| ||||
Posted in reply to Don | On 13.05.2011 10:25, Don wrote: > Are you talking about *finalizers* or *destructors* ? Destructors as defined in D spec. There are no finalizers (yet), AFAIK. > Throwing from inside a destructor should definitely work (unlike C++). How? Destructor is called by the GC when object is deleted. When and where (which thread) this happens is unknown, it is done outside of regular flow of execution - so who and where can catch this exception? So, like any other uncatched exception, it will terminate the program. > But finalizers should probably be nothrow. Once they are implemented :) In any case, as long as there is no try/catch around GC collection, I see little use for exceptions apart from terminating the program. If, however, we are talking about using try/catch blocks inside of destructors - then of course, this should be possible. /Alexander |
May 13, 2011 Re: The GC, destructors, exceptions and memory corruption | ||||
---|---|---|---|---|
| ||||
Posted in reply to Vladimir Panteleev | On 13.05.2011 10:12, Vladimir Panteleev wrote:
> Yes, but what if it's handled (there's a try/catch block around the allocation or fullCollect call that invoked the GC)?
Oh, that case... Sure, if GC is buggy and throw causes GC allocation in turn... then we have a problem, of course, but of course, this should work - normally.
/Alexander
|
May 13, 2011 Re: The GC, destructors, exceptions and memory corruption | ||||
---|---|---|---|---|
| ||||
Posted in reply to Daniel Gibson | On Fri, 13 May 2011 11:41:04 +0300, Daniel Gibson <metalcaedes@gmail.com> wrote: > Am 13.05.2011 10:33, schrieb Vladimir Panteleev: >> On Fri, 13 May 2011 11:22:11 +0300, Daniel Gibson >> <metalcaedes@gmail.com> wrote: >> >>> It may be sane to just define that destructors are nothrow and if they >>> throw anyway to terminate the program. >>> >>> What is the current behaviour anyway? ;) >> >> D2 throws a FinalizeError (which is an Error, so "not recoverable"). > > So the program is terminated? In that case you don't really have to > worry about the state of the GC, right? I guess, but this requires that the user does not use catch(Object) or catch(Throwable). I don't know if this is acceptable for SafeD, for example. -- Best regards, Vladimir mailto:vladimir@thecybershadow.net |
May 13, 2011 Re: The GC, destructors, exceptions and memory corruption | ||||
---|---|---|---|---|
| ||||
Posted in reply to Vladimir Panteleev | On Fri, 13 May 2011 12:28:01 +0300, Vladimir Panteleev <vladimir@thecybershadow.net> wrote: > I guess, but this requires that the user does not use catch(Object) or catch(Throwable). Also just catch { ... }, of course (I don't understand why that's in the language at all). -- Best regards, Vladimir mailto:vladimir@thecybershadow.net |
May 13, 2011 Re: The GC, destructors, exceptions and memory corruption | ||||
---|---|---|---|---|
| ||||
Posted in reply to Vladimir Panteleev | On 2011-05-13 04:34:06 -0400, "Vladimir Panteleev" <vladimir@thecybershadow.net> said: > Come to think of it, SafeD shouldn't allow accessing anything on the heap in finalizers as well... Back to bug 4621. <http://d.puremagic.com/issues/show_bug.cgi?id=4621> -- Michel Fortin michel.fortin@michelf.com http://michelf.com/ |
May 13, 2011 Re: The GC, destructors, exceptions and memory corruption | ||||
---|---|---|---|---|
| ||||
Posted in reply to Daniel Gibson | On Fri, 13 May 2011 11:41:04 +0300, Daniel Gibson <metalcaedes@gmail.com> wrote: > So the program is terminated? In that case you don't really have to > worry about the state of the GC, right? After looking again at it, my patch actually does "the right thing" and locks out the GC after a finalizer exception (any attempt to access the GC from that point will instantly throw), so I've sent the pull requests. Thanks for the feedback. -- Best regards, Vladimir mailto:vladimir@thecybershadow.net |
May 13, 2011 Re: The GC, destructors, exceptions and memory corruption | ||||
---|---|---|---|---|
| ||||
Posted in reply to Alexander | Alexander wrote: > On 13.05.2011 10:25, Don wrote: > >> Are you talking about *finalizers* or *destructors* ? > > Destructors as defined in D spec. There are no finalizers (yet), AFAIK. The things in classes which the spec calls "destructors" are finalizers, not destructors. > >> Throwing from inside a destructor should definitely work (unlike C++). > > How? Destructor is called by the GC when object is deleted. When and where (which thread) this happens is unknown, it is done outside of regular flow of execution - so who and where can catch this exception? So, like any other uncatched exception, > it will terminate the program. If the GC calls it, it's a finalizer, not a destructor. Structs have destructors, and it's perfectly OK to throw inside them. |
May 13, 2011 Re: The GC, destructors, exceptions and memory corruption | ||||
---|---|---|---|---|
| ||||
Posted in reply to Vladimir Panteleev | Vladimir Panteleev wrote: > On Fri, 13 May 2011 11:25:01 +0300, Don <nospam@nospam.com> wrote: > >> Alexander wrote: >>> On 13.05.2011 06:53, Vladimir Panteleev wrote: >>> >>>> Thus, my question is: what's the expected behavior of D programs when a destructor throws? >>> I would say, the only expected (and correct, IMHO) behavior should be termination of the program because of unhandled exception. >>> /Alexander >> >> Are you talking about *finalizers* or *destructors* ? >> >> Throwing from inside a destructor should definitely work (unlike C++). >> But finalizers should probably be nothrow. > > How would you distinguish the two in the language? Class destructors = finalizers? Yes. struct destructor = destructor > Come to think of it, SafeD shouldn't allow accessing anything on the heap in finalizers as well... Yeah. It's pretty hard to come up with a use case for a finalizer. |
May 13, 2011 Re: The GC, destructors, exceptions and memory corruption | ||||
---|---|---|---|---|
| ||||
Posted in reply to Don | == Quote from Don (nospam@nospam.com)'s article
> Yeah. It's pretty hard to come up with a use case for a finalizer.
This is why I'm so interested in improving D's GC yet have shown so little interest in this bug. I can't even figure out what finalizers are for and basically never use them. Even in the cases where I have used them before to get around false pointer issues, I now realize that such uses were actually latent race conditions.
|
Copyright © 1999-2021 by the D Language Foundation