Open GoogleCodeExporter opened 9 years ago
Of course, even greater concern is the amount of true positives and whether
users will be willing to fix them. We'll see :)
Original comment by konstant...@gmail.com
on 26 Feb 2014 at 9:29
Probably we can figure out some strictness levels for this feature. E.g. do not
report, report more, report even more, report all.
I do not have ideas what patterns have higher chances of being "false/true
positives" (in the sense of being harmful and users are willing to fix them)
for now.
Original comment by dvyu...@google.com
on 26 Feb 2014 at 9:49
[deleted comment]
When I used that feature with Insure++ (a long time ago), I almost never
saw any false positives. The only false positive that I remember, what
a program that was comparing 2 unrelated pointers both in the stack, to
find out in which direction the stack was growing. But that's a fairly
odd and rare thing to do in the first place. I think it was in the
only false positive I ever saw was in this function in Vim source code
(in vim/src/os_unix.c):
696 static int stack_grows_downwards;
697
698 /*
699 * Find out if the stack grows upwards or downwards.
700 * "p" points to a variable on the stack of the caller.
701 */
702 static void
703 check_stack_growth(p)
704 char *p;
705 {
706 int i;
707
708 stack_grows_downwards = (p > (char *)&i);
709 }
...
3053 int i;
3054
3055 check_stack_growth((char *)&i);
The comparison at line 708 is undefined as it is true
if the stack is growing in one direction or false if
the stack is growing in the other direction. That's
precisely what that function is checking, so in that
case it was a false positive.
Thinking about it, it should not complain when checking in both
directions as the pointer comparison is then valid. Example:
int *p;
int a[10];
...
if (p >= &a[0] && p < &a[10])
{
/* This always OK */
...
}
if (p >= &a[0])
{
/* This has undefined behaviour if p and &a[0] are unrelated pointers */
}
Original comment by dominiqu...@gmail.com
on 26 Feb 2014 at 10:31
The false positives you describe are equally bad under asan's
stack-use-after-return
checker and I am not afraid of them. They are rare, and could be suppressed by
__attribute__((no_sanitize_address)).
What I am afraid of is *true* positives that users will not want to fix,
e.g. std::set<void *> or some such.
Original comment by konstant...@gmail.com
on 26 Feb 2014 at 10:41
In my previous comment, I wrote about the example function
check_stack_growth(...):
> The comparison at line 708 is undefined as it is true
> if the stack is growing in one direction or false if
> the stack is growing in the other direction. That's
> precisely what that function is checking, so in that
> case it was a false positive.
Thinking about it, I wonder whether it's a false positive
or not. What happens if the compiler inlines function
check_stack_growth(...)? Then I'm not sure any more whether
the function will returns the expected result. So I'm
not sure how portable this function is and warning about
it does not look bad to me.
Original comment by dominiqu...@gmail.com
on 26 Feb 2014 at 10:42
First kill: http://llvm.org/viewvc/llvm-project?view=revision&revision=202266
This is my own asan test,
it was putting malloc-ed pointers into a vector and then sorting them
(on purpose! the test is very asan-specific)
Original comment by konstant...@gmail.com
on 26 Feb 2014 at 2:02
Filed a related bug for clang/llvm:
http://llvm.org/bugs/show_bug.cgi?id=18989
Original comment by konstant...@gmail.com
on 27 Feb 2014 at 12:53
Original comment by ramosian.glider@gmail.com
on 30 Jul 2015 at 9:05
Adding Project:AddressSanitizer as part of GitHub migration.
Original comment by ramosian.glider@gmail.com
on 30 Jul 2015 at 9:06
Original issue reported on code.google.com by
konstant...@gmail.com
on 26 Feb 2014 at 8:16