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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
