[PATCH] D25199: [ubsan] Sanitize deleted pointers

[Vedant Kumar via cfe-commits]

vsk added a comment.

In https://reviews.llvm.org/D25199#560023, @kcc wrote:

> > Maybe we could call this `-fpoison-dangling-ptrs` and force users to be more explicit about opting into this behavior change. That would remove some of the constraints usually placed on new sanitizer checks (e.g support for executing after the error triggers, support for custom trap functions).
>
> What's wrong with -fsanitize=SOMETHING? (the exact value of SOMETHING is debatable)


My concern is that using -fsanitize=something could confuse users who expect support for -fsanitize-trap-function=custom_func or -fsanitize-recover=something. But it's a minor concern. I am fine with -fsanitize=something if we leave it out of the default -fsanitize=undefined checks.

>>> @kcc Is it safe to add a handler for segv and continue program execution as normal? I'm asking because I haven't tried that before, and am guessing you have experience with this from working on asan.
> 
> Not sure I understand your question. 
>  We can add an optional SEGV handler to ubsan that will see the address on which we failed, and say something like "faulty address is close to 0xDEADBEEF, use of dangling pointer suspected. <STACK_TRACE>"
>  Then exit.

My question was about whether it's possible to resume normal program execution after printing the stack trace from the segv handler. I had assumed this is not possible, and (mistakenly) thought that you were suggesting this approach.

>>> One more thing to consider: how will we support -fsanitize-trap=value-after-delete?
> 
> This will essentially only have the trap mode, it will not support -fsanitize-recover

OK.


https://reviews.llvm.org/D25199