On Tue, Oct 4, 2016 at 11:43 AM, Matt Gingell wrote:
> Hi Richard,
>
> Thanks for your analysis.
>
> This patch is intended to mitigate use-after-free bugs. In that context a
> “define strict behavior for invalid pointer values” we could deploy in
> production code would be very useful. Maybe cal
Hi Richard,
Thanks for your analysis.
This patch is intended to mitigate use-after-free bugs. In that context a
“define strict behavior for invalid pointer values” we could deploy in
production code would be very useful. Maybe calling this a sanitizer is
misleading, and instead it could be pr
On Mon, Oct 3, 2016 at 2:59 PM, Peter Collingbourne wrote:
> pcc added a reviewer: rsmith.
> pcc added a comment.
>
> It seems to me that this sanitizer would break the semantics of otherwise
> well-defined programs. For example:
>
> int *x = nullptr;
> delete x;
> if (x != nullptr) {
>
filcab added a comment.
In https://reviews.llvm.org/D25199#560061, @vsk wrote:
> 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 su
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
kcc added a comment.
> 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, supp
vsk added a comment.
In https://reviews.llvm.org/D25199#559849, @pcc wrote:
> It seems to me that this sanitizer would break the semantics of otherwise
> well-defined programs. For example:
>
> int *x = nullptr;
> delete x;
> if (x != nullptr) {
> // normally unreachable
> }
>
>
> It
pcc added a reviewer: rsmith.
pcc added a comment.
It seems to me that this sanitizer would break the semantics of otherwise
well-defined programs. For example:
int *x = nullptr;
delete x;
if (x != nullptr) {
// normally unreachable
}
It may be that a null comparison would be enough
vsk added a comment.
In https://reviews.llvm.org/D25199#559797, @kcc wrote:
> >> will just crash without further reporting
>
> I agree, and we can address that by having special logic in ubsan's segv
> handler.
> This does not have to be in this patch.
@kcc Is it safe to add a handler for
kcc added a comment.
>> will just crash without further reporting
I agree, and we can address that by having special logic in ubsan's segv
handler.
This does not have to be in this patch.
Also, I am not sure about the actual constant.
DEADBEEF is commonly recognized poison valued, but on a
kcc added a reviewer: pcc.
kcc added a comment.
In https://reviews.llvm.org/D25199#559407, @vsk wrote:
> It looks like programs which trip -fsanitize-value-after-delete will just
> crash without further reporting, which isn't in keeping with the way other
> ubsan checks are implemented.
>
> IMO
vsk added a comment.
It looks like programs which trip -fsanitize-value-after-delete will just crash
without further reporting, which isn't in keeping with the way other ubsan
checks are implemented.
IMO, address sanitizer is better-equipped to diagnose this issue.
https://reviews.llvm.org/D2
gingell created this revision.
gingell added reviewers: cfe-commits, kcc.
This patch adds a "value-after-delete" sanitizer, which will
invalidate the value of a pointer passed in a delete expression.
For instance, when -fsanitize=value-after-delete is passed:
int *foo = new int;
delete foo;
// f
13 matches
Mail list logo
