www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Access Violation Tracking

reply "Bauss" <jj_1337 live.dk> writes:
Is there any way to track down access violations, instead of me 
having to look through my source code manually.

I have a pretty big source code and an access violation happens 
at runtime, but it's going to be a nightmare looking through it 
all to find the access violation. Not to mention all the tests I 
have to run.

So if there is a way to catch an access violation and find out 
where it occured it would be appreciated!
Nov 05 2014
next sibling parent "thedeemon" <dlang thedeemon.com> writes:
On Wednesday, 5 November 2014 at 11:09:42 UTC, Bauss wrote:

 Is there any way to track down access violations, instead of me 
 having to look through my source code manually.

 I have a pretty big source code and an access violation happens 
 at runtime, but it's going to be a nightmare looking through it 
 all to find the access violation. Not to mention all the tests 
 I have to run.

 So if there is a way to catch an access violation and find out 
 where it occured it would be appreciated!


What OS are you using? Did you run any debugger?
Nov 05 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Bauss:


 Is there any way to track down access violations, instead of me 
 having to look through my source code manually.

 I have a pretty big source code and an access violation happens 
 at runtime, but it's going to be a nightmare looking through it 
 all to find the access violation. Not to mention all the tests 
 I have to run.

 So if there is a way to catch an access violation and find out 
 where it occured it would be appreciated!


This was discussed some times, and Walter is against this, but I 
think he is wrong, and eventually things will change. So I think 
this discussion should be brought to the main D newsgroup again.

Ideally in non-release mode D should put asserts where a access 
violation could happen. But I don't know how much slowdown this 
will cause. If practical real tests show that the slowdown is 
excessive, then a compiler switch could be added to activate 
those asserts.

Bye,
bearophile
Nov 05 2014
next sibling parent "Bauss" <jj_1337 live.dk> writes:
On Wednesday, 5 November 2014 at 11:27:02 UTC, thedeemon wrote:

 On Wednesday, 5 November 2014 at 11:09:42 UTC, Bauss wrote:

 Is there any way to track down access violations, instead of 
 me having to look through my source code manually.

 I have a pretty big source code and an access violation 
 happens at runtime, but it's going to be a nightmare looking 
 through it all to find the access violation. Not to mention 
 all the tests I have to run.

 So if there is a way to catch an access violation and find out 
 where it occured it would be appreciated!


 What OS are you using? Did you run any debugger?


I am running Windows, but I am not using any debugger.
I was more looking for a build in function.

On Wednesday, 5 November 2014 at 11:31:01 UTC, bearophile wrote:

 Bauss:


 Is there any way to track down access violations, instead of 
 me having to look through my source code manually.

 I have a pretty big source code and an access violation 
 happens at runtime, but it's going to be a nightmare looking 
 through it all to find the access violation. Not to mention 
 all the tests I have to run.

 So if there is a way to catch an access violation and find out 
 where it occured it would be appreciated!


 This was discussed some times, and Walter is against this, but 
 I think he is wrong, and eventually things will change. So I 
 think this discussion should be brought to the main D newsgroup 
 again.

 Ideally in non-release mode D should put asserts where a access 
 violation could happen. But I don't know how much slowdown this 
 will cause. If practical real tests show that the slowdown is 
 excessive, then a compiler switch could be added to activate 
 those asserts.

 Bye,
 bearophile


I agree with you completely thathe is wrong. There should 
definitely be a way to find access violations within the program. 
I cannot add asserts and checks everywhere since performance is 
my number one priority within my program, so I have to make sure 
that the access violation cannot happen in the first place.
However it's a bit hard to track down access violations in big 
programs if you don't know when exactly it occured and where 
exactly it occured.
Nov 05 2014
prev sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 5 November 2014 at 11:31:01 UTC, bearophile wrote:

 This was discussed some times, and Walter is against this, but 
 I think he is wrong, and eventually things will change.


An access violation already thrown on Win32. Just catch a 
Throwable in main and write out exception.toString. But you do 
need to have debugging info compiled in to get a readable 
backtrace with dmd -g.
Nov 05 2014
prev sibling next sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Wednesday, 5 November 2014 at 11:09:42 UTC, Bauss wrote:

 Is there any way to track down access violations, instead of me 
 having to look through my source code manually.

 I have a pretty big source code and an access violation happens 
 at runtime, but it's going to be a nightmare looking through it 
 all to find the access violation. Not to mention all the tests 
 I have to run.

 So if there is a way to catch an access violation and find out 
 where it occured it would be appreciated!


If you're on Linux, you can turn SEGVs into Errors:

     import etc.linux.memoryerror;
     registerMemoryErrorHandler();
Nov 05 2014
next sibling parent "Bauss" <jj_1337 live.dk> writes:
On Wednesday, 5 November 2014 at 11:39:21 UTC, Marc Schütz wrote:

 On Wednesday, 5 November 2014 at 11:09:42 UTC, Bauss wrote:

 Is there any way to track down access violations, instead of 
 me having to look through my source code manually.

 I have a pretty big source code and an access violation 
 happens at runtime, but it's going to be a nightmare looking 
 through it all to find the access violation. Not to mention 
 all the tests I have to run.

 So if there is a way to catch an access violation and find out 
 where it occured it would be appreciated!


 If you're on Linux, you can turn SEGVs into Errors:

     import etc.linux.memoryerror;
     registerMemoryErrorHandler();


I am on Windows, but thanks that might come in handy when I have 
to test my program on other platforms.
Nov 05 2014
prev sibling next sibling parent reply =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
On Wednesday, 5 November 2014 at 11:39:21 UTC, Marc Schütz wrote:

 If you're on Linux, you can turn SEGVs into Errors:

     import etc.linux.memoryerror;
     registerMemoryErrorHandler();


Why isn't such a useful feature activated by default? Performance 
reasons?
Nov 06 2014
parent reply ketmar via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Thu, 06 Nov 2014 20:13:02 +0000
"Nordl=C3=B6w" via Digitalmars-d-learn <digitalmars-d-learn puremagic.com>
wrote:


 On Wednesday, 5 November 2014 at 11:39:21 UTC, Marc Sch=C3=BCtz wrote:

 If you're on Linux, you can turn SEGVs into Errors:

     import etc.linux.memoryerror;
     registerMemoryErrorHandler();


=20
 Why isn't such a useful feature activated by default? Performance=20
 reasons?


'cause it's not really that useful. uncaught (by the proper checks)
segmentation fault is the serious bug, program must crach and spit out
postmortem dump. without interceptions crach point (which is written
into the dump too) will be right at the place where it shots it's foot.
and with signal handler installed... who knows?

crash+coredump is alot more useful than intercepting error and...
trying to recover from undefined state? or just exit to OS, losing
valuable information about a crash?
Nov 06 2014
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 11/6/14 10:22 PM, ketmar via Digitalmars-d-learn wrote:

 On Thu, 06 Nov 2014 20:13:02 +0000
 "Nordlöw" via Digitalmars-d-learn <digitalmars-d-learn puremagic.com>
 wrote:


 On Wednesday, 5 November 2014 at 11:39:21 UTC, Marc Schütz wrote:

 If you're on Linux, you can turn SEGVs into Errors:

      import etc.linux.memoryerror;
      registerMemoryErrorHandler();


 Why isn't such a useful feature activated by default? Performance
 reasons?


 'cause it's not really that useful. uncaught (by the proper checks)
 segmentation fault is the serious bug, program must crach and spit out
 postmortem dump


In an environment that you don't control, the default behavior is likely 
to print "Segmentation Fault" and exit. No core dump, no nothing.

This leads to unhelpful bug reports, and seeing if you can get your 
client to "try to make it happen again with this debug build, or with 
the shell set up to make a core dump".

I think it would be nice to be able to check if a core dump is enabled, 
and if not, register the handler by default.

-Steve
Nov 06 2014
next sibling parent reply ketmar via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Thu, 06 Nov 2014 22:45:23 -0500
Steven Schveighoffer via Digitalmars-d-learn
<digitalmars-d-learn puremagic.com> wrote:


 In an environment that you don't control, the default behavior is likely=


=20

 to print "Segmentation Fault" and exit. No core dump, no nothing.
=20
 This leads to unhelpful bug reports, and seeing if you can get your=20
 client to "try to make it happen again with this debug build, or with=20
 the shell set up to make a core dump".


README file, prerequisites: "please, turn on coredump feature if you
plan to send bug reports. thank you."

btw, that's why i'm against so-called "release builds" with debug
features not only turned off, but not compiled at all. every build must
be "release build", and no debug features should be ommited. when i
stopped to making "debug builds" and started to pass my clients the
same builds i'm using as developer, things becomes much easier.
Nov 06 2014
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 11/6/14 11:43 PM, ketmar via Digitalmars-d-learn wrote:

 On Thu, 06 Nov 2014 22:45:23 -0500
 Steven Schveighoffer via Digitalmars-d-learn
 <digitalmars-d-learn puremagic.com> wrote:


 In an environment that you don't control, the default behavior is likely
 to print "Segmentation Fault" and exit. No core dump, no nothing.

 This leads to unhelpful bug reports, and seeing if you can get your
 client to "try to make it happen again with this debug build, or with
 the shell set up to make a core dump".


 README file, prerequisites: "please, turn on coredump feature if you
 plan to send bug reports. thank you."


This doesn't help. We must live in the real world with real customers :)

-Steve
Nov 07 2014
parent ketmar via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Fri, 07 Nov 2014 08:49:34 -0500
Steven Schveighoffer via Digitalmars-d-learn
<digitalmars-d-learn puremagic.com> wrote:


 On 11/6/14 11:43 PM, ketmar via Digitalmars-d-learn wrote:

 On Thu, 06 Nov 2014 22:45:23 -0500
 Steven Schveighoffer via Digitalmars-d-learn
 <digitalmars-d-learn puremagic.com> wrote:


 In an environment that you don't control, the default behavior is like=






ly

 to print "Segmentation Fault" and exit. No core dump, no nothing.

 This leads to unhelpful bug reports, and seeing if you can get your
 client to "try to make it happen again with this debug build, or with
 the shell set up to make a core dump".


 README file, prerequisites: "please, turn on coredump feature if you
 plan to send bug reports. thank you."


=20
 This doesn't help. We must live in the real world with real customers :)


i do. this really helps when clients wants their problem to be solved.
and if they doesn't, it's sufficient to answer like "thank you for your
report, we are working on it" (and then dumping that "report"
to /dev/null). this works perfectly.
Nov 07 2014
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Friday, 7 November 2014 at 03:45:23 UTC, Steven Schveighoffer 
wrote:

 In an environment that you don't control, the default behavior 
 is likely to print "Segmentation Fault" and exit. No core dump, 
 no nothing.


If you let the exception propagate into OS, by default Windows 
creates memory dump.
Nov 11 2014
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 11/11/14 10:14 AM, Kagamin wrote:

 On Friday, 7 November 2014 at 03:45:23 UTC, Steven Schveighoffer wrote:

 In an environment that you don't control, the default behavior is
 likely to print "Segmentation Fault" and exit. No core dump, no nothing.


 If you let the exception propagate into OS, by default Windows creates
 memory dump.


Windows is a different story. You actually get a reasonable result.

On Unix flavors, you get a signal, and by default, an exit, with the 
following message:

Segmentation fault
prompt>

No history, no core dump (generally this is off by default), no 
information as to where it occurred, why it occurred. Nothing.

-Steve
Nov 11 2014
prev sibling parent reply =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
On Friday, 7 November 2014 at 03:22:59 UTC, ketmar via 
Digitalmars-d-learn wrote:

 crash+coredump is alot more useful than intercepting error 
 and...
 trying to recover from undefined state? or just exit to OS, 
 losing
 valuable information about a crash?


Together with the DUB package backtrace this gives really nice 
default behaviour printing stacktrace where memory fault occurred.

For details see my show case at:
https://github.com/nordlow/justd/blob/master/t_errorHandler.d
Nov 07 2014
next sibling parent reply ketmar via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Fri, 07 Nov 2014 13:52:33 +0000
"Nordl=C3=B6w" via Digitalmars-d-learn <digitalmars-d-learn puremagic.com>
wrote:


 On Friday, 7 November 2014 at 03:22:59 UTC, ketmar via=20
 Digitalmars-d-learn wrote:

 crash+coredump is alot more useful than intercepting error=20
 and...
 trying to recover from undefined state? or just exit to OS,=20
 losing
 valuable information about a crash?


=20
 Together with the DUB package backtrace this gives really nice=20
 default behaviour printing stacktrace where memory fault occurred.
=20
 For details see my show case at:
 https://github.com/nordlow/justd/blob/master/t_errorHandler.d


but i don't want stacktrace! i want coredump, so i can inspect the
program, it's variables and it's internal state. i want to know *how*
*exactly* program manages to shot itself in the foot.

easily catchable segfaults are not surviving testing. and if segfault
survives, most of the time it's not enough to get stack trace, i need
to fire gdb with coredump and try to understand what the hell is going
on there.

i also developed a habit of writing assert()s before dereferencing
pointers first time (including class refs) in appropriate places, so
i'll got that stack trace for free. ;-) and i never turning off that
asserts in "release builds".
Nov 07 2014
next sibling parent reply "Nikolay" <sibnick gmail.com> writes:
 i also developed a habit of writing assert()s before 
 dereferencing
 pointers first time (including class refs) in appropriate 
 places, so
 i'll got that stack trace for free. ;-) and i never turning off 
 that
 asserts in "release builds".


About null pointer deref & core dump

I think, it is problem. Dland on windows gives stacktrace without 
any problem. In general it is expected behavior for many people 

is bad idea has core dump for null deref in linux by default.

As I remember current linux handler is dirty hack, and it is main 
reason why it is disabled by default.
Nov 07 2014
parent ketmar via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Sat, 08 Nov 2014 06:23:39 +0000
Nikolay via Digitalmars-d-learn <digitalmars-d-learn puremagic.com>
wrote:


 I think, it is problem. Dland on windows gives stacktrace without=20
 any problem. In general it is expected behavior for many people=20

 is bad idea has core dump for null deref in linux by default.


this is the only choice. invoking file i/o from signal handler is UB.
Nov 07 2014
prev sibling parent reply "Nikolay" <sibnick gmail.com> writes:
 i also developed a habit of writing assert()s before 
 dereferencing
 pointers first time (including class refs) in appropriate 
 places, so
 i'll got that stack trace for free. ;-) and i never turning off 
 that
 asserts in "release builds".


If we can't rely on system level may be we should have internal 
check for null deref like for array bounds?
Nov 08 2014
parent ketmar via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Sat, 08 Nov 2014 11:46:16 +0000
Nikolay via Digitalmars-d-learn <digitalmars-d-learn puremagic.com>
wrote:


 i also developed a habit of writing assert()s before=20
 dereferencing
 pointers first time (including class refs) in appropriate=20
 places, so
 i'll got that stack trace for free. ;-) and i never turning off=20
 that
 asserts in "release builds".


=20
 If we can't rely on system level may be we should have internal=20
 check for null deref like for array bounds?


my memory can cheat me, but i bet that this was discussed before and
Walter is against it.
Nov 08 2014
prev sibling next sibling parent ketmar via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Fri, 07 Nov 2014 13:52:33 +0000
"Nordl=C3=B6w" via Digitalmars-d-learn <digitalmars-d-learn puremagic.com>
wrote:


 On Friday, 7 November 2014 at 03:22:59 UTC, ketmar via=20
 Digitalmars-d-learn wrote:

 crash+coredump is alot more useful than intercepting error=20
 and...
 trying to recover from undefined state? or just exit to OS,=20
 losing
 valuable information about a crash?


=20
 Together with the DUB package backtrace this gives really nice=20


...undefined behavior. this code is not only unsafe (even in perverted
D "safety"), it's plainly wrong. you are not allowed to call most of
the libc functions from signal handler. actually, the things you can do
safely in signal handler is setting some variable or calling _exit(2).
ok, there are some more syscalls which are safe, but obviously not
FILE* i/o from libc.

so it doesn't matter wether i want coredumps or you want stack traces,
the only correct solution is coredumps. printing stack trace from
signal handler is UB, and it works only by accident. there is no good
in using code that relies on UB.
Nov 07 2014
prev sibling next sibling parent "H. S. Teoh via Digitalmars-d-learn" <digitalmars-d-learn puremagic.com> writes:
On Sat, Nov 08, 2014 at 08:50:20AM +0200, ketmar via Digitalmars-d-learn wrote:

 On Fri, 07 Nov 2014 13:52:33 +0000
 "Nordlöw" via Digitalmars-d-learn <digitalmars-d-learn puremagic.com>
 wrote:
 

 On Friday, 7 November 2014 at 03:22:59 UTC, ketmar via 
 Digitalmars-d-learn wrote:

 crash+coredump is alot more useful than intercepting error and...
 trying to recover from undefined state? or just exit to OS, losing
 valuable information about a crash?


 
 Together with the DUB package backtrace this gives really nice 


 ...undefined behavior. this code is not only unsafe (even in perverted
 D "safety"), it's plainly wrong. you are not allowed to call most of
 the libc functions from signal handler. actually, the things you can
 do safely in signal handler is setting some variable or calling
 _exit(2).  ok, there are some more syscalls which are safe, but
 obviously not FILE* i/o from libc.
 
 so it doesn't matter wether i want coredumps or you want stack traces,
 the only correct solution is coredumps. printing stack trace from
 signal handler is UB, and it works only by accident. there is no good
 in using code that relies on UB.


Some time ago deadalnix gave a neat (if scary) hack where the signal
handler overwrites its return address on the stack to redirect the code
to a handler that operates outside signal handler context, so it has no
restrictions on syscalls that it can use. Since by the time control
passes to that handler, the "official" signal handler has returned, you
can do whatever you want without running into UB. (Of course,
overwriting return addresses on the stack arguably qualifies as UB, but
hey, when a man is desperate...)


T

-- 
"Real programmers can write assembly code in any language. :-)" -- Larry Wall
Nov 07 2014
prev sibling parent ketmar via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Fri, 7 Nov 2014 22:58:38 -0800
"H. S. Teoh via Digitalmars-d-learn"
<digitalmars-d-learn puremagic.com> wrote:


 Some time ago deadalnix gave a neat (if scary) hack where the signal
 handler overwrites its return address on the stack to redirect the code
 to a handler that operates outside signal handler context, so it has no
 restrictions on syscalls that it can use.


it's implementation detail which is free to change. as i said, such
code relies on implementation details and "defined undefined behavior".
there is no guarantees that you will get the same stack for signal
handler and for application. sure, we can do some tricks that exploiting
black magic knowledge, but that's what i surely don't want to see in
normal code.

besides, segfault can be raised inside libc, for example. passing bad
argument to some fXXX() operation and BOOM! at this point libc can hold
some locks, has some internal state variables initialized and some not,
and so on. so no malloc(), no FILE* i/o, no formatted printing, etc.
only bare syscalls. and replacing return address will not help in this
case.
Nov 07 2014
prev sibling parent reply "Gary Willoughby" <dev nomad.so> writes:
On Wednesday, 5 November 2014 at 11:39:21 UTC, Marc Schütz wrote:

 If you're on Linux, you can turn SEGVs into Errors:

     import etc.linux.memoryerror;
     registerMemoryErrorHandler();


This is really cool, (and at the risk of sounding foolish) what 
is the benefit of doing this?
Nov 08 2014
next sibling parent ketmar via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Sat, 08 Nov 2014 15:51:58 +0000
Gary Willoughby via Digitalmars-d-learn
<digitalmars-d-learn puremagic.com> wrote:


 On Wednesday, 5 November 2014 at 11:39:21 UTC, Marc Sch=C3=BCtz wrote:

 If you're on Linux, you can turn SEGVs into Errors:

     import etc.linux.memoryerror;
     registerMemoryErrorHandler();


=20
 This is really cool, (and at the risk of sounding foolish) what=20
 is the benefit of doing this?


adding a little more undefined behavior to your program. UB is always
nice! ;-)
Nov 08 2014
prev sibling parent "Kagamin" <spam here.lot> writes:
On Saturday, 8 November 2014 at 15:51:59 UTC, Gary Willoughby 
wrote:

 This is really cool, (and at the risk of sounding foolish) what 
 is the benefit of doing this?


It turns segfault into normal exception with a stack trace, so 
you see where it failed right away.
Nov 11 2014
prev sibling next sibling parent Andrej Mitrovic via Digitalmars-d-learn writes:
On Nov 5, 2014 12:10 PM, "Bauss via Digitalmars-d-learn" <
digitalmars-d-learn puremagic.com> wrote:

 Is there any way to track down access violations, instead of me having to


look through my source code manually.

Whenever you don't get a stack trace on Windows, it's 99% guaranteed you're
calling a null function pointer.


 I have a pretty big source code and an access violation happens at


runtime, but it's going to be a nightmare looking through it all to find
the access violation. Not to mention all the tests I have to run.

 So if there is a way to catch an access violation and find out where it


occured it would be appreciated!
Nov 06 2014
prev sibling parent reply Etienne <etcimon gmail.com> writes:
On 2014-11-05 6:09 AM, Bauss wrote:

 Is there any way to track down access violations, instead of me having
 to look through my source code manually.

 I have a pretty big source code and an access violation happens at
 runtime, but it's going to be a nightmare looking through it all to find
 the access violation. Not to mention all the tests I have to run.

 So if there is a way to catch an access violation and find out where it
 occured it would be appreciated!


I've seen a lot more invalid memory operation errors since the GC calls 
destructors. Letting the GC destroy objects out of order can be the 
issue. We might have to make an associative array of static global flags 
(debug bool[void*]) for each object to see if it was destroyed, and use 
asserts in the destructors / update the associative array, as a new idiom.
Nov 09 2014
parent reply ketmar via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Sun, 09 Nov 2014 09:33:29 -0500
Etienne via Digitalmars-d-learn <digitalmars-d-learn puremagic.com>
wrote:


 I've seen a lot more invalid memory operation errors since the GC calls=20
 destructors. Letting the GC destroy objects out of order can be the=20
 issue. We might have to make an associative array of static global flags=


=20

 (debug bool[void*]) for each object to see if it was destroyed, and use=20
 asserts in the destructors / update the associative array, as a new idiom.


that's where i want precise GC to come into play. i really want it to
nullify all internal pointers to finalized objects before calling
destructor. sure, this can modify alot of members, so it must be opt-in
feature.

ah, and stop calling class finalizers "destructors" helps too. they
are... well... finalizers, not destructors. ;-)
Nov 09 2014
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Sunday, 9 November 2014 at 14:45:11 UTC, ketmar via 
Digitalmars-d-learn wrote:

 On Sun, 09 Nov 2014 09:33:29 -0500
 Etienne via Digitalmars-d-learn 
 <digitalmars-d-learn puremagic.com>
 wrote:


 I've seen a lot more invalid memory operation errors since the 
 GC calls destructors. Letting the GC destroy objects out of 
 order can be the issue. We might have to make an associative 
 array of static global flags (debug bool[void*]) for each 
 object to see if it was destroyed, and use asserts in the 
 destructors / update the associative array, as a new idiom.


 that's where i want precise GC to come into play. i really want 
 it to
 nullify all internal pointers to finalized objects before 
 calling
 destructor. sure, this can modify alot of members, so it must 
 be opt-in
 feature.

 ah, and stop calling class finalizers "destructors" helps too. 
 they
 are... well... finalizers, not destructors. ;-)


I once suggested to introduce dedicated finalizers that get 
called instead of the destructor by the GC, and nobody argued 
against it ;-)

They would be applicable to both classes and structs. A finalizer 
may only perform a subset of what's allowed in destructors, and 
the compiler might be able to verify that. For DRYness, the 
finalizer can optionally be called by the destructor, because 
everything that is valid in a finalizer should also be valid in a 
destructor.
Nov 10 2014
parent ketmar via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Mon, 10 Nov 2014 11:13:11 +0000
via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> wrote:


 On Sunday, 9 November 2014 at 14:45:11 UTC, ketmar via=20
 Digitalmars-d-learn wrote:

 On Sun, 09 Nov 2014 09:33:29 -0500
 Etienne via Digitalmars-d-learn=20
 <digitalmars-d-learn puremagic.com>
 wrote:


 I've seen a lot more invalid memory operation errors since the=20
 GC calls destructors. Letting the GC destroy objects out of=20
 order can be the issue. We might have to make an associative=20
 array of static global flags (debug bool[void*]) for each=20
 object to see if it was destroyed, and use asserts in the=20
 destructors / update the associative array, as a new idiom.


 that's where i want precise GC to come into play. i really want=20
 it to
 nullify all internal pointers to finalized objects before=20
 calling
 destructor. sure, this can modify alot of members, so it must=20
 be opt-in
 feature.

 ah, and stop calling class finalizers "destructors" helps too.=20
 they
 are... well... finalizers, not destructors. ;-)


=20
 I once suggested to introduce dedicated finalizers that get=20
 called instead of the destructor by the GC, and nobody argued=20
 against it ;-)
=20
 They would be applicable to both classes and structs. A finalizer=20
 may only perform a subset of what's allowed in destructors, and=20
 the compiler might be able to verify that. For DRYness, the=20
 finalizer can optionally be called by the destructor, because=20
 everything that is valid in a finalizer should also be valid in a=20
 destructor.


by the way, constructors are essentially initializers, 'cause they
called with already constructed objects. and not only constructed, but
even initialized with default values.

i was always disappointed by the fact that i can't change the way
object *constructed* in *constructor*.
Nov 10 2014