Access Violation Tracking

[H. S. Teoh via Digitalmars-d-learn]

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