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.

> 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?

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
> > 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?
my memory can cheat me, but i bet that this was discussed before and Walter is against it.

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?

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ü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?
adding a little more undefined behavior to your program. UB is always nice! ;-)

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.

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. ;-)

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.

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 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.
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*.

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.