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 from different languages (Java, C#). So from my point of view it 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
 from different languages (Java, C#). So from my point of view it=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
 "Nordlw" 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