Access Violation Tracking

[ketmar via Digitalmars-d-learn]

On Fri, 7 Nov 2014 22:58:38 -0800
"H. S. Teoh via Digitalmars-d-learn"
<digitalmars-d-learn at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-learn/attachments/20141108/c3da0c4f/attachment.sig>