[Bug demangler/79099] Memory leak in cplus-dem.c:2232
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79099 Kostya Serebryany changed: What|Removed |Added CC||kcc at gcc dot gnu.org --- Comment #2 from Kostya Serebryany --- We are already fuzzing the LLVM demangler on https://github.com/google/oss-fuzz (a free continuous fuzzing service for OSS). Binutils demangler is very welcome there as well.
[Bug sanitizer/77982] deadlock in asan thread initialization/interception.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77982 --- Comment #5 from Kostya Serebryany --- (In reply to Pawel Sikora from comment #3) > (In reply to Kostya Serebryany from comment #2) > > Is -flto important here? > > Does this happen with clang? (does not happen for me) > > Does this happen if you use statically linked asan (-static-libasan)? > > ad1). lto isn't important. > ad2). with static libasan testcase works. > ad3). i can't verify with clang on fedora 24 due to linking error: > > clang++ -fuse-ld=gold -g2 -O -fsanitize=address s.cpp -shared -o s.so -fPIC > clang++ -fuse-ld=gold -g2 -O -fsanitize=address m.cpp -o m > /usr/bin/ld.gold: error: cannot open > /usr/bin/../lib64/clang/3.8.0/lib/linux/libclang_rt.asan-x86_64.a: No such > file or directory > /usr/bin/ld.gold: error: cannot open > /usr/bin/../lib64/clang/3.8.0/lib/linux/libclang_rt.asan_cxx-x86_64.a: No > such file or directory Apparently, the clang installation is broken. Besides 3.8 is too old and is irrelevant anyway. Your test case works for me with clang trunk (clang links asan runtime statically) > m.cpp:5: error: undefined reference to '__asan_init' > m.cpp:5: error: undefined reference to '__asan_version_mismatch_check_v6' > m.cpp:5: error: undefined reference to '__asan_register_globals' > m.cpp:5: error: undefined reference to '__asan_unregister_globals' >> ./s.so: undefined symbol: __asan_option_detect_stack_use_after_return This does not happen with clang. So, this looks like a gcc-specific bug, probably related to dynamic linking of asan-rt. Hopefully the GCC folks can help. Ejecting myself from here. If something like this reproduces in clang trunk, please summon me back.
[Bug sanitizer/77982] deadlock in asan thread initialization/interception.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77982 --- Comment #2 from Kostya Serebryany --- Is -flto important here? Does this happen with clang? (does not happen for me) Does this happen if you use statically linked asan (-static-libasan)?
[Bug sanitizer/78028] ASAN doesn't find memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78028 --- Comment #1 from Kostya Serebryany --- interestingly, this works for me with clang
[Bug sanitizer/77963] inconsistent (false?) leaks detection.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77963 --- Comment #1 from Kostya Serebryany --- lsan does not work with ptrace. There is https://github.com/google/sanitizers/issues/728 for it. We don't have plans to fix it, but the change I sent for review yesterday causes lsan to complain loudly instead of producing false reports. If you know how to *fix* it, i.e. to make lsan work with ptrace -- please tell.
[Bug sanitizer/77567] ASAN: Bugus error "alloc-dealloc-mismatch (malloc vs operator delete [])" with C++17's over-aligned types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77567 --- Comment #6 from Kostya Serebryany --- (In reply to Jakub Jelinek from comment #5) > Created attachment 39612 [details] > pr77567-2.patch > > Slightly larger patch, which attempts to diagnose that, but fails to do so, > because asan_allocator.cc only has: > u32 alloc_type: 2; > and we now need 3 bits instead of just 2. > Dmitry, is there any possibility to free one bit for this in ChunkHeader? There are no bits left. But do we need these new states here? Can't we reuse the from_memalign field? Also, please remember that we can not accept patches from this buganizer -- they need to go via http://llvm.org/docs/Phabricator.html
[Bug sanitizer/77567] ASAN: Bugus error "alloc-dealloc-mismatch (malloc vs operator delete [])" with C++17's over-aligned types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77567 --- Comment #2 from Kostya Serebryany --- (In reply to Jakub Jelinek from comment #1) > I guess libasan needs to add the new C++17 aligned new operator entrypoints. > Dmitry, are you going to add this upstream yourself, or should I cook a > patch? Jaukub, yes, a patch upstream would be welcome. In clang we don't have -std=c++17 yet, so I won't even be able to test it there.
[Bug sanitizer/69840] two ASAN help nits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69840 --- Comment #3 from Kostya Serebryany --- You don't :) The agreement between the teams was that the code in gcc is a verbatim copy of upstream. (Well, there was a single-line difference at some point) If you break this assumption, the next merge will undo your change. Or the next merge will become impossible.
[Bug sanitizer/70712] False positive from AddressSanitizer with use of 'alignas'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70712 --- Comment #1 from Kostya Serebryany --- Does not happen with clang: clang++ -fsanitize=address alignas.cc -std=c++11 && ./a.out So this is gcc-specific.
[Bug c++/68399] New: c++11 default initialization of a large array: slow compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68399
Bug ID: 68399
Summary: c++11 default initialization of a large array: slow
compile
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kcc at gcc dot gnu.org
Target Milestone: ---
Reproducible with 4.8.2 and fresh trunk (r230509).
% gcc -O1 z.cpp -std=c++11 -c
#ifndef SZ
# define SZ 16
#endif
struct Range {
short B, E;
Range() : B(0), E(0) {}
};
struct ArrayOfRanges {
Range LabelRanges[1 << SZ] = {};
};
ArrayOfRanges *AOR = new ArrayOfRanges();
This code will take ~10 minutes to compile at -O1
The larger the SZ is the longer it takes.
[Bug sanitizer/67865] ASAN crashes on thread creation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67865 --- Comment #2 from Kostya Serebryany --- (In reply to dominik.strasser from comment #1) > Host system: CentOS release 6.4 (Final) > glibc: glibc-2.12-1.132.el6.x86_64 glibc-2.12 might be a bit too old. We don't test with it, and this code is very glibc-dependent. Also, the asan run-time in gcc has not been updated for at least 1 year. Do you observe the same behavior with fresh clang?
[Bug sanitizer/67513] ASAN: Not optimal shadow value check (unlikely condition checked in fast path)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67513
--- Comment #5 from Kostya Serebryany ---
(In reply to Yury Gribov from comment #1)
> (In reply to Andrey Ryabinin from comment #0)
> > (shadow value is usually zero).
>
> What makes you think so? AFAIU for less-than-8-byte scalars it's always
> non-zero. I vaguely remember than Kostya did something like this in Clang
> case and it resulted in negligeable improvement.
The code in llvm uses branch weights to indicate that the slow path
is rarely taken.
if (ClAlwaysSlowPath || (TypeSize < 8 * Granularity)) {
// We use branch weights for the slow path check, to indicate that the slow
// path is rarely taken. This seems to be the case for SPEC benchmarks.
TerminatorInst *CheckTerm = SplitBlockAndInsertIfThen(
Cmp, InsertBefore, false, MDBuilder(*C).createBranchWeights(1,
10));
The measurements were done on SPEC 2016 lng ago,
I have no idea whether this is still a good heuristic.
I remember that the difference was not huge, but enough to justify
one extra parameter.
[Bug sanitizer/67168] Asan crashes on program startup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67168 Kostya Serebryany changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Kostya Serebryany --- - don't add -lsan. -fsanitize=address is all you need. - please provide more details. - check if lsan works for you on a simple synthetic test case, e.g. grab some from https://github.com/llvm-mirror/compiler-rt/tree/master/test/lsan/TestCases - does the lsan in fresh clang work for you? Since the bug report is not actionable at this point I am closing it. Please reopen when the above bullets are checked.
[Bug sanitizer/65662] AddressSanitizer CHECK failed: ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_allocator.h:835 "((res)) < ((kNumPossibleRegions))" (0x3ffb49, 0x80000)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65662 --- Comment #5 from Kostya Serebryany --- AArch64 is being discussed at https://groups.google.com/forum/#!topic/address-sanitizer/YzYRJEvVimw Please join the discussion. We, the primary maintainers of asan, have no access to AArch64 boxes yet, so we rely on others here.
[Bug sanitizer/65662] AddressSanitizer CHECK failed: ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_allocator.h:835 "((res)) < ((kNumPossibleRegions))" (0x3ffb49, 0x80000)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65662 --- Comment #4 from Kostya Serebryany --- AArch64 is being discussed at https://groups.google.com/forum/#!topic/address-sanitizer/YzYRJEvVimw Please join the discussion. We, the primary maintainers of asan, have no access to AArch64 boxes yet, so we rely on others here.
[Bug sanitizer/65285] __asan_describe_address crashes when used with global variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65285 Kostya Serebryany changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #10 from Kostya Serebryany --- (In reply to Peter Wu from comment #9) > Tested with > clang version 3.7.0 (http://llvm.org/git/clang.git > 6b7e300a9c14a2ff364d8ef8a0f7510378f38dbc) (http://llvm.org/git/llvm > 258b7710d59c086656f7b26f02326d7ca69d71fd) > > (http://llvm.org/git/compiler-rt.git > 70b3c4464a4067db2cd9862736611fdf6739f451) > > The output is still: > AddressSanitizer can not describe address in more detail (wild memory access > suspected). > > I can however live with the -fno-common workaround (which sounds like a good > idea overall). Exactly, we recommend using -fno-common with asan for C to find more bugs. > I'll leave it up to you whether it will be closed as WONTFIX. > > Thanks for your hints!
[Bug sanitizer/65285] __asan_describe_address crashes when used with global variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65285 --- Comment #8 from Kostya Serebryany --- (In reply to Peter Wu from comment #7) > (In reply to Kostya Serebryany from comment #6) > > > How does your GCC behave with the test case? The sanitizer code in GCC is > > > imported from Clang, I believe, so it probably does not crash either? > > > > I get this: > > ~/gcc-inst/bin/gcc -fsanitize=address -static-libasan d.c && ./a.out > > AddressSanitizer can not describe address in more detail (wild memory access > > suspected). > > I guess this is better than crashing. Is it possible to report something > better? Can't it at least report the type and address? Since asan does not instrument this global it knows nothing about it. Sure, it is possible to provide better diagnostic, but this is nowhere near the top of the things we are planing to work on. Frankly, this looks like a relatively low value feature. > > > Did you check the GCC trunk? > > It took a while to get the build environment, but now I can confirm that I > see the same wild memory access error (tested with r221125). Let me double-check with the fresh GCC trunk. Does fresh Clang trunk work for you?
[Bug sanitizer/65285] __asan_describe_address crashes when used with global variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65285 --- Comment #6 from Kostya Serebryany --- > How does your GCC behave with the test case? The sanitizer code in GCC is > imported from Clang, I believe, so it probably does not crash either? I get this: ~/gcc-inst/bin/gcc -fsanitize=address -static-libasan d.c && ./a.out AddressSanitizer can not describe address in more detail (wild memory access suspected). Did you check the GCC trunk?
[Bug sanitizer/65285] __asan_describe_address crashes when used with global variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65285
--- Comment #4 from Kostya Serebryany ---
(In reply to Peter Wu from comment #3)
> GCC 4.9.2 cannot include the headers, it blows up on lines such as:
> In file included from
> /usr/lib/clang/3.5.1/include/sanitizer/common_interface_defs.h:16:0,
> from
> /usr/lib/clang/3.5.1/include/sanitizer/asan_interface.h:17,
> from :1:
> /usr/lib/clang/3.5.1/include/stddef.h:42:42: error: missing binary operator
> before token "("
> #if !defined(_PTRDIFF_T) || __has_feature(modules)
> ...
>
> (gcc -I/usr/lib/clang/3.5.1/include ...)
>
> With clang 3.5.1, it works, but *only* with "-x c++" and not "-x c".
This should work with clang trunk.
I think I know what your problem is.
In C, the globals by default have common linkage and asan does not instrument
them at all and thus can not properly report them.
Use -fno-common with C.
https://code.google.com/p/address-sanitizer/wiki/Flags
[Bug sanitizer/65285] __asan_describe_address crashes when used with global variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65285
--- Comment #1 from Kostya Serebryany ---
What happens if you properly include sanitizer/asan_interface.h?
This is what I see with fresh clang:
% cat d.cc
#include
int foo[10];
int main(void) {
__asan_describe_address(&foo);
}
% clang -fsanitize=address d.cc && ./a.out
0x0135c820 is located 0 bytes inside of global variable 'foo' defined in
'd.cc:2:5' (0x135c820) of size 40
%
[Bug sanitizer/65285] __asan_describe_address crashes when used with global variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65285 --- Comment #2 from Kostya Serebryany --- and for gcc: % ~/gcc-inst/bin/g++ -fsanitize=address -static-libasan d.cc && ./a.out 0x0134f900 is located 0 bytes inside of global variable 'foo' defined in 'd.cc:2:5' (0x134f900) of size 40 %
[Bug bootstrap/63888] [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #34 from Kostya Serebryany ---
(In reply to Jakub Jelinek from comment #31)
> Any progress on this?
>
> If not, I'm considering doing:
> --- libsanitizer/asan/asan_globals.cc.jj 2014-11-14 00:10:34.0
> +0100
> +++ libsanitizer/asan/asan_globals.cc 2015-02-20 11:43:33.179177767 +0100
> @@ -148,7 +148,9 @@ static void RegisterGlobal(const Global
>CHECK(AddrIsInMem(g->beg));
>CHECK(AddrIsAlignedByGranularity(g->beg));
>CHECK(AddrIsAlignedByGranularity(g->size_with_redzone));
> - if (flags()->detect_odr_violation) {
> + // This "ODR violation" detection is fundamentally incompatible with
> + // how GCC registers globals. Disable as useless until rewritten
> upstream.
> + if (0 && flags()->detect_odr_violation) {
> // Try detecting ODR (One Definition Rule) violation, i.e. the situation
> // where two globals with the same name are defined in different
> modules.
> if (__asan_region_is_poisoned(g->beg, g->size_with_redzone)) {
> for now.
Sorry, this got pushed back in the queue...
Sure, feel free to commit something like this.
Slightly better place is at the definition of detect_odr_violation -- change
the default to 0 and mark the change with some visible markers.
Obviously we'll need to do a proper fix upstream before the next merge.
Frankly, I am not at all motivated to do any significant surgery in the llvm
compiler instrumentation because for me everything works fine.
We can extend the Global struct to have a boolean (bit?) that says whether we
are checking for ODRs (as you suggested above). This will be a new ABI break.
Not a big deal, of course.
I wonder if we can somehow else detect that the module is compiled with GCC and
disable the checking in that case?
[Bug sanitizer/64435] [5 Regression] Bootstrap failure in libsanitizer on AArch64 with Linux kernel <= 3.15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64435 --- Comment #23 from Kostya Serebryany --- Can we move the discussion to the asan issue tracker? https://code.google.com/p/address-sanitizer/issues/list There is already quite a bit of aarch64 discussion at https://code.google.com/p/address-sanitizer/issues/detail?id=246 Not all of the asan developers are looking at the gcc buganizer and the fix will need to go to the upstream anyway.
[Bug tree-optimization/64330] [5 Regression] IPA-ICF merges const exported vars that could be addressable in other TUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64330 --- Comment #4 from Kostya Serebryany --- So, maybe the ODR checker in the current form is not that useless. Sorry, couldn't resist :)
[Bug bootstrap/63888] [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888 Kostya Serebryany changed: What|Removed |Added CC||richard-gccbugzilla@metafoo ||.co.uk --- Comment #22 from Kostya Serebryany --- Summoning more folks
[Bug bootstrap/63888] [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888 --- Comment #20 from Kostya Serebryany --- > Is this clear? This is on access of the b1 variable defined in main.c, > certainly not anything around f variable defined in libfoo.c. Yea. Thanks. Pondering... I am still not convinced that this code is good (even if it is C-standard-compliant).
[Bug bootstrap/63888] [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888 --- Comment #18 from Kostya Serebryany --- (In reply to Jakub Jelinek from comment #17) > (In reply to Kostya Serebryany from comment #16) > > Frankly, I realize that I don't understand the subtleties of this problem. > > :( > > > > First, if this is C++ we clearly have a bug (ODR violation) and we are > > done. > > So it is an ODR violation in C++, but you won't report it (remember, the > binary is not instrumented), just it will misbehave (can mark valid memory > of other vars in the binary as poisoned, e.g.). > > > Then, if this is C w/o any extra flags we will not instrument these globals. > > Not true, the vars are initialized, thus are not common. Or the var in the > binary could be common, and the var in the shared library not, etc. > And I've actually verified both clang and gcc instrument it. > > Registering something assuming padding has been added (and aligned) when you > don't have a control on it is just wrong, and the local alias is an very > easy way to avoid it. I am disoriented. Can you please give a full repro (with command lines, etc) where we'll now produce a false positive (in clang or in gcc)?
[Bug bootstrap/63888] [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #16 from Kostya Serebryany ---
(In reply to Jakub Jelinek from comment #15)
> (In reply to Kostya Serebryany from comment #14)
> > We should be careful when instrumenting something that can be redefined
> > because the
> > definition may be no-instrumented.
>
> But that is a strong argument why what GCC does is desirable and not what
> LLVM does.
> Say you have:
> int f = 4;
> int g = 5;
> int foo (int *p) { return *p; }
> in libfoo.c and
> int f = 4;
> int g = 5;
> int foo (int *);
> int main ()
> {
> return foo (&f) - 4;
> }
> Suppose libfoo.c is compiled/linked with -fsanitize=address -fpic -shared.
> Suppose main.c is compiled without -fsanitize=address.
> GCC will use in registration of global symbols in libfoo.c the local alias
> to f and g, so registers something that in the end is not used, because f in
> the executable comes earlier in the search scope. But registers something
> that is known to be properly padded for asan.
> LLVM doesn't use a local alias, and so will happily register the f and g
> symbols in the binary, but as if they had the padding which they most
> probably don't. So you can end up with false positives or false negatives
> that way.
> But when you use local aliases, obviously the current way of ODR checking
> can't work and should use symbol names instead.
Frankly, I realize that I don't understand the subtleties of this problem. :(
First, if this is C++ we clearly have a bug (ODR violation) and we are done.
Then, if this is C w/o any extra flags we will not instrument these globals.
Done.
Finally, if this is C with -fno-common, I am not sure if the C standard covers
this and how we should behave.
[Bug bootstrap/63888] [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #14 from Kostya Serebryany ---
(In reply to Yury Gribov from comment #13)
> (In reply to Kostya Serebryany from comment #12)
> > But for this example in C the globals will not get instrumented, unless
> > -fno-common is given.
>
> BTW I think everyone already pairs this with -fsanitize=address, otherwise
> sanitization of globals becomes so weak.
Dunno. That's what we recommend.
>
> >> If LLVM uses global symbols instead of local aliases, it is more expensive.
> >> You can have aliases/weakrefs etc. to symbols, and those still aren't ODR
> >> violations.
> >
> > But these again should not be instrumented by asan at all. No?
>
> Wouldn't that cause false negatives for internal references to local aliases?
We should be careful when instrumenting something that can be redefined because
the
definition may be no-instrumented.
Consider a case where
a.c has a weakref (or whatever else that can be redefined) and
b.c had a regular definition.
Then, a.c is instrumented and b.c is not. Bad.
>
> > Never seen a case like this ("registered multiple times for multiple
> > addresses").
> > Can you give an example?
>
> How about this: say some global variable xyz is defined both in executable
> and in shared library. Now
> 1) if xyz isn't exported from executable, it will not be available to shlib;
> so exe's internal references will bind to exe's definition but shlib's
> references will bind to shlib's definition
> 2) if xyz is exported from executable but shlib is linked with -Bsymbolic,
> shlib's internal references will bind to shlib's implementation
> 3) RTLD_DEEPBIND could also alter symbol resolution order in a shlib
[Bug sanitizer/59410] tsan tests fail with address randomization disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #36 from Kostya Serebryany --- While we are at it, H.J., is there any hope with https://bugzilla.kernel.org/show_bug.cgi?id=66721 ?
[Bug sanitizer/64265] [5 Regression] r217669 broke tsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64265 --- Comment #16 from Kostya Serebryany --- > Kostya, can you say anything about llvm? On the tsan issue you said: > "We'll need a kind of RAII for tsan entry/exit hooks. When we are adding > tsan instrumentation, we need to create a fake class object with a ctor and > dtor." I am still pretty confident that this is the only viable solution (the fix should be done in Clang, not LLVM). I did not try to actually implement it yet. > > Which suggests that you wanted to do it in a similar way in llvm. > > If we decide to it this way in both compilers, then no support in runtime is > required, and gcc can well implement it ahead of llvm. Absolutely.
[Bug bootstrap/63888] [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #12 from Kostya Serebryany ---
(In reply to Jakub Jelinek from comment #9)
> (In reply to Kostya Serebryany from comment #8)
> > > You haven't responded about the language thing, there is no such thing as
> > > ODR in C or Fortran, so you shouldn't report it.
> >
> > In LLVM, I do not (and should not) know what source language is being
> > compiled.
>
> Sounds like LLVM limitation.
>
> > The differences between languages are represented in the linkage types
> > of the globals. E.g. a regular global in C will not be instrumented at all
> > unless -fno-common is given. I.e. the difference is not in the source
> > language
> > but in the linkage type of the globals.
>
> I believe your
> http://llvm.org/klaus/compiler-rt/blob/
> 0926de35c9357aa1a5c47d3a618d6c72f9e8f085/test/asan/TestCases/Linux/odr-
> violation.cc
> example is valid in C
But for this example in C the globals will not get instrumented, unless
-fno-common is given.
> , and commonly used (sure, more commonly with functions
> than with variables, but even with variables). Furthermore, the kind of ODR
> detection in libasan isn't really ODR detection, you are instead checking if
> the same global is registered multiple times. GCC intentionally registers
> local aliases of the globals, so that the same global isn't registered
> multiple times if it is defined by multiple shared libraries or binary and
> some shared library - each TU registers the vars local to it, rather than
> trying to register globals in a completely different shared library.
> If LLVM uses global symbols instead of local aliases, it is more expensive.
> You can have aliases/weakrefs etc. to symbols, and those still aren't ODR
> violations.
But these again should not be instrumented by asan at all. No?
>
> An ODR violation is IMHO something different, it is the case where you have
> the same symbol name (but, you'd need to distinguish between globally
> visible symbols that should be ODR checked and local symbols and/or symbols
> from languages you don't want to check for it) registered multiple times for
> multiple addresses.
Never seen a case like this ("registered multiple times for multiple
addresses").
Can you give an example?
>> So you'd need to hash based on the symbol name if
> marked for ODR checking, and check if the same (non-comdat) global isn't
> registered several times.
[Bug bootstrap/63888] [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888 --- Comment #8 from Kostya Serebryany --- (sorry for delay, I missed the last comment) > Generally, we do want to instrument even artificial variables, and on many > of them buffer overflow is possible. Yea, agree. > > > I.e. is a buffer overflow on these variables possible? > > > > If we don't instrument them we won't report an ODR violation. > > > > >> GCC with -fmerge-all-constants also merges many read-only constants, > > >> even addressable ones, when they have the same content. > > > > Then I guess we may have other false positives. > > We may want to disable -fmerge-all-constants under asan > > You haven't responded about the language thing, there is no such thing as > ODR in C or Fortran, so you shouldn't report it. In LLVM, I do not (and should not) know what source language is being compiled. The differences between languages are represented in the linkage types of the globals. E.g. a regular global in C will not be instrumented at all unless -fno-common is given. I.e. the difference is not in the source language but in the linkage type of the globals. % clang -S -o - -emit-llvm glob.c @GLOBAL = common global i32 0, align 4 % clang -S -o - -emit-llvm glob.c -fno-common @GLOBAL = global i32 0, align 4 % clang++ -x c++ -S -o - -emit-llvm glob.c @GLOBAL = global i32 0, align 4 Can you give an example in C where we do not want to check for ODRs, yet the basic asan instrumentation is legal? > There are 31 (or 63) bits left in __has_dynamic_init field, can't one bit be > used for whether ODR should be reported or not? That will still mean an API change, something I like to avoid when possible.
[Bug sanitizer/63958] [5 Regression] bootstrap failure in the sanitizer libs on sparc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63958 --- Comment #6 from Kostya Serebryany --- I am not at war with anyone and if I am, I give up and surrender. But whoever wants the sanitizers to work on SPARC [s]he will have to work with us upstream. We can not fix build failures on SPARC upstream because we don't have access to SPARC machines and there is no public buildbot with SPARC. If no one needs sanitizers on SPARC and all you care about is that GCC builds on SPARC, just disable the sanitizers for SPARC. This is my last response here. For constructive discussion please start sending patches upstream.
[Bug sanitizer/63958] [5 Regression] bootstrap failure in the sanitizer libs on sparc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63958 --- Comment #3 from Kostya Serebryany --- I am very sorry that you are so upset, but the workflow will not change. All changes to sanitizer files (except for GCC-specific tests and make files) have to go to upstream first. If any change goes directly to GCC it will get overwritten by a following merge from upstream. (merge is the wrong name for process actually. The right name would be "copy").
[Bug sanitizer/63958] [5 Regression] bootstrap failure in the sanitizer libs on sparc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63958 --- Comment #1 from Kostya Serebryany --- Please send patches upstream: https://code.google.com/p/address-sanitizer/wiki/HowToContribute
[Bug bootstrap/63888] [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888 --- Comment #6 from Kostya Serebryany --- (In reply to Yury Gribov from comment #5) > Perhaps ODR check should check that names of global variables match before > issuing warning? The variables are generated by the compiler, right? (These are switch tables) Do we want to instrument them at all? I.e. is a buffer overflow on these variables possible? If we don't instrument them we won't report an ODR violation. >> GCC with -fmerge-all-constants also merges many read-only constants, even >> addressable ones, when they have the same content. Then I guess we may have other false positives. We may want to disable -fmerge-all-constants under asan
[Bug sanitizer/63927] AddressSanitizer painfully slow on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63927 Kostya Serebryany changed: What|Removed |Added CC||eugeni.stepanov at gmail dot com, ||samsonov at google dot com --- Comment #7 from Kostya Serebryany --- (In reply to Markus Trippelsdorf from comment #6) > See: > http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html#STACK Then someone needs to implement the appropriate unwinder in sanitizer_common/sanitizer_stacktrace.cc and submit the patch for review upstream. https://code.google.com/p/address-sanitizer/wiki/HowToContribute
[Bug sanitizer/63927] AddressSanitizer painfully slow on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63927 --- Comment #4 from Kostya Serebryany --- Why can't we use frame pointers on PPC? So far I have not seen any implementation of unwinder not based on FPs that was fast enough for ASan. ASan unwinds the stack on every malloc/free and thus it is very sensitive to the unwinder performance.
[Bug sanitizer/63564] -fsanitize=address obscures access to free memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63564 --- Comment #4 from Kostya Serebryany --- (In reply to Bernd Edlinger from comment #3) > In the original example (it was ported from windows, > and the windows semaphores are completely immune > against this kind of error) the sem_post were in > *another* thread and there were several milliseconds > between the free the next malloc. So this is > already a really, really hard to find bug. > But what I don't understand, why the malloc does > *not* crash when address sanitizer is used. If the program has undefined behavior then the program's behavior is, well, undefined. You can not expect malloc to crash if there is a bug in the code. asan's malloc does not rely on malloc headers for bookeeping so it did not crash. > The same for thread sanitizer, it does not spot > the error, and the error does not happen in debug > builds only in release builds. Good point. tsan does intercept sem_post/sem_wait but does not detect when there is a use-after-free on it (we do it for pthread_mutex_lock though). Dmitry, You may want to add that to tsan.
[Bug sanitizer/63564] -fsanitize=address obscures access to free memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63564 --- Comment #2 from Kostya Serebryany --- We don't intercept sem_post/sem_wait and don't instrument glibc where they are implemented. Sadly, the same applies to quite a few other glibc functions. In future we may have fully instrumented glibc, but in the meantime we need to add more interceptors. Patches are welcome, see https://code.google.com/p/address-sanitizer/wiki/HowToContribute Most likely sanitizer_common/sanitizer_common_interceptors.inc will need to be modified.
[Bug c/63418] false positive with -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63418 --- Comment #3 from Kostya Serebryany --- Thanks for confirming the current state of this warning :)
[Bug c/63418] false positive with -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63418 --- Comment #1 from Kostya Serebryany --- Created attachment 33626 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33626&action=edit w1.c attached the repro
[Bug c/63418] New: false positive with -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63418
Bug ID: 63418
Summary: false positive with -Wmaybe-uninitialized
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kcc at gcc dot gnu.org
I know there are some known false positives with -Wmaybe-uninitialized, so this
might be a dup. I'd like to document this one just in case this is another
corner case.
The test comes from a slightly modified glibc sources.
Tested with the fresh gcc trunk r215730.
% gcc w1.c -std=gnu99 -c -Wmaybe-uninitialized -O2
w1.c: In function ‘parse_expression.constprop’:
w1.c:13311:28: warning: ‘extra’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
if (name_len == extra[idx]
^
w1.c:13500:24: note: ‘extra’ was declared here
const unsigned char *extra;
Looking at the code:
"extra" is defined w/o initializer:
13500 const unsigned char *extra;
Then, it is initialized under if (nrules):
13522 if (nrules) {
...
13533 extra =
nrules never changes again.
The warning complains about "extra" being used in seek_collating_symbol_entry
w/o being initialied.
There are two calls to seek_collating_symbol_entry, they look like this:
13337 if (nrules != 0) {
13338 int32_t elem, idx;
13339 elem = seek_collating_symbol_entry(br_elem->opr.name, sym_name_len,
13456 if (nrules != 0) {
13457 elem = seek_collating_symbol_entry(name, name_len, symb_table,
table_size,
So, in both cases seek_collating_symbol_entry is called if nrules != 0, i.e.
'extra' is initialized.
If this is something new and unexpected I can prepare a better minimized
example, but I don't want to waste time if this is known.
I wasn't able to reproduce this on a tiny example.
[Bug sanitizer/61293] asan can not find left buffer overflow of new[]-allocated buffer, frontend help needed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61293 --- Comment #4 from Kostya Serebryany --- FTR, this has been implemented in Clang (Itanium ABI only for now): clang: http://llvm.org/viewvc/llvm-project?view=revision&revision=216434 asan: http://llvm.org/viewvc/llvm-project?rev=214711&view=rev test: http://llvm.org/viewvc/llvm-project?rev=216494&view=rev
[Bug driver/62105] sanitizer libraries in wrong command line position in link spec file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62105 Kostya Serebryany changed: What|Removed |Added CC||eugeni.stepanov at gmail dot com, ||kcc at gcc dot gnu.org, ||samsonov at google dot com --- Comment #1 from Kostya Serebryany --- clang uses -whole-archive: clang -fsanitize=thread a.cc -v "/usr/bin/ld" -whole-archive ...lib/clang/3.5.0/lib/linux/libclang_rt.tsan-x86_64.a -no-whole-archive ... I believe this is the only right thing to do. Placing the tsan run-time after the objects will have other nasty side effects (Alexey, Evgenyi may remember exactly which)
[Bug sanitizer/61978] implement blacklist for sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978 --- Comment #8 from Kostya Serebryany --- (In reply to Daniel Pinol from comment #7) > thank you everybody for your great feedback! > > @kostya: I provide here the full log. Even removing the #if's, it still > aborts. strict_memcmp=0 worked like a charm. Thanks! Good. Formally this is a bug, but in most cases not a very harmful one. So, just continue using strict_memcmp=0 > > I guess there's no way to just report the errors but not abort execution, > right? Right, asan exits on first error. (First entry in FAQ: https://code.google.com/p/address-sanitizer/wiki/AddressSanitizer#FAQ) > > > 0x09de51cc is located 52 bytes to the left of global variable '*.LC2' from > '/home/dani/svn/robot/sources/src/interaction/gui/touchscreen/ReemH/ > videoWindow/VideoWindow.cpp' (0x9de5200) of size 1 > '*.LC2' is ascii string '' > 0x09de51cc is located 0 bytes to the right of global variable '*.LC1' from > '/home/dani/svn/robot/sources/src/interaction/gui/touchscreen/ReemH/ > videoWindow/VideoWindow.cpp' (0x9de51c0) of size 12 > '*.LC1' is ascii string 'VideoWindow' > SUMMARY: AddressSanitizer: global-buffer-overflow > ../../.././libsanitizer/asan/asan_interceptors.cc:325 __interceptor_memcmp > Shadow bytes around the buggy address: > 0x213bc9e0: 04 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00 > 0x213bc9f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x213bca00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x213bca10: 01 f9 f9 f9 f9 f9 f9 f9 01 f9 f9 f9 f9 f9 f9 f9 > 0x213bca20: 01 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00 > =>0x213bca30: 00 00 00 00 00 00 00 00 00[04]f9 f9 f9 f9 f9 f9 > 0x213bca40: 01 f9 f9 f9 f9 f9 f9 f9 00 00 01 f9 f9 f9 f9 f9 > 0x213bca50: 00 00 01 f9 f9 f9 f9 f9 00 07 f9 f9 f9 f9 f9 f9 > 0x213bca60: 00 05 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00 > 0x213bca70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x213bca80: 00 01 f9 f9 f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9 > Shadow byte legend (one shadow byte represents 8 application bytes): > Addressable: 00 > Partially addressable: 01 02 03 04 05 06 07 > Heap left redzone: fa > Heap right redzone: fb > Freed heap region: fd > Stack left redzone: f1 > Stack mid redzone: f2 > Stack right redzone: f3 > Stack partial redzone: f4 > Stack after return: f5 > Stack use after scope: f8 > Global redzone: f9 > Global init order: f6 > Poisoned by user:f7 > Contiguous container OOB:fc > ASan internal: fe > ==19590==ABORTING
[Bug sanitizer/61978] implement blacklist for sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978 --- Comment #5 from Kostya Serebryany --- Also check if strict_memcmp=0 helps you. https://code.google.com/p/address-sanitizer/wiki/Flags
[Bug sanitizer/61978] implement blacklist for sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978 --- Comment #4 from Kostya Serebryany --- Note that the blacklist can not disable the checking inside the memcmp interceptor. But it will disable instrumenting globals in QT, so if this is a global from QT (you did not post the full log) you will not see the error.
[Bug sanitizer/61978] implement blacklist for sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978 --- Comment #2 from Kostya Serebryany --- Yea. This has been discussed a couple of times before. using an attribute in the source is clearly the preferable way. Unfortunately, it is not always technically possible, so we *have* to use the blacklists. The major use cases: a) third_party code that can not be easily modified b) needs to blacklist an entire source directory c) blacklist should be applied to a type, not a function In Chromium we have these: http://src.chromium.org/viewvc/chrome/trunk/src/tools/memory/tsan_v2/ignores.txt?revision=279695 http://src.chromium.org/viewvc/chrome/trunk/src/tools/msan/blacklist.txt?revision=284946 http://src.chromium.org/viewvc/chrome/trunk/src/tools/ubsan_vptr/blacklist.txt?revision=285951 http://src.chromium.org/viewvc/chrome/trunk/src/third_party/instrumented_libraries/blacklists/asan/libglib2.0-0.txt?revision=282959 http://src.chromium.org/viewvc/chrome/trunk/src/third_party/instrumented_libraries/blacklists/msan/libx11-6.txt?revision=282959
[Bug sanitizer/61771] Regressions in ASan testsuite on ARM Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61771 --- Comment #5 from Kostya Serebryany --- > > Of course, it would be awesome if we could synchronize > > (and document somewhere) FP stack layout between GCC and Clang Isn't this what ARM should be doing? >> Perhaps we should just disable fast unwind on ARM? You will slowdown asan to the point where Valgrind will become preferable
[Bug c++/61288] valgrind finds problem in build_conditional_expr_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61288 Kostya Serebryany changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #3 from Kostya Serebryany --- Seems to have appeared after r210281
[Bug c++/61288] valgrind finds problem in build_conditional_expr_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61288 --- Comment #2 from Kostya Serebryany --- Created attachment 33107 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33107&action=edit 61288.cc Somewhat minimized reproducer: cc1plus -mtune=generic -march=x86-64 -std=gnu++11 61288.cc
[Bug c++/61288] valgrind finds problem in build_conditional_expr_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61288 Kostya Serebryany changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-11 CC||kcc at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Kostya Serebryany --- I see this bug as well while running asan-ified or msan-ified gcc r212448 Besides just being a bug it also prevents me from testing gcc with asan and msan Minimized reproducer coming soon. ==6753==ERROR: AddressSanitizer: heap-use-after-free on address 0x6210001c49a8 at pc 0x5df403 bp 0x7fff67fe9a70 sp 0x7fff67fe9a68 READ of size 1 at 0x6210001c49a8 thread T0 #0 0x5df402 in build_conditional_expr_1 gcc/cp/call.c:4842:11 #1 0x5db148 in build_conditional_expr gcc/cp/call.c:5089:9 #2 0x965849 in build_x_conditional_expr gcc/cp/typeck.c:6073:10 #3 0x88f88d in cp_parser_question_colon_clause gcc/cp/parser.c:8146:10 #4 0x88f88d in cp_parser_assignment_expression gcc/cp/parser.c:8185 0x6210001c49a8 is located 168 bytes inside of 4064-byte region [0x6210001c4900,0x6210001c58e0) freed by thread T0 here: #0 0x5a3871 in free #1 0x7fa9dca702a7 in obstack_free #2 0x5dcf0a in build_conditional_expr_1 gcc/cp/call.c:4822:7 #3 0x5db148 in build_conditional_expr gcc/cp/call.c:5089:9 #4 0x965849 in build_x_conditional_expr gcc/cp/typeck.c:6073:10 #5 0x88f88d in cp_parser_question_colon_clause gcc/cp/parser.c:8146:10 #6 0x88f88d in cp_parser_assignment_expression gcc/cp/parser.c:8185 previously allocated by thread T0 here: #0 0x5a3b49 in __interceptor_malloc #1 0x2907384 in xmalloc #2 0x7fa9dca701c5 in _obstack_newchunk /build/buildd/eglibc-2.15/malloc/obstack.c:271 #3 0x5ce9c6 in conversion_obstack_alloc gcc/cp/call.c:615:7 #4 0x5c7029 in alloc_conversion gcc/cp/call.c:724:22 #5 0x5c7029 in build_identity_conv gcc/cp/call.c:1049 #6 0x5c7029 in build_user_type_conversion_1 gcc/cp/call.c:3620 #7 0x5d0297 in implicit_conversion gcc/cp/call.c:1820:14 #8 0x5dbf3f in build_conditional_expr_1 gcc/cp/call.c:4769:15 #9 0x5db148 in build_conditional_expr gcc/cp/call.c:5089:9 #10 0x965849 in build_x_conditional_expr gcc/cp/typeck.c:6073:10 #11 0x88f88d in cp_parser_question_colon_clause gcc/cp/parser.c:8146:10 #12 0x88f88d in cp_parser_assignment_expression gcc/cp/parser.c:8185
[Bug other/61016] use of uninitialized memory in gcc/config/i386/i386.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61016 --- Comment #3 from Kostya Serebryany --- Ping. Any interest? The bug is still present in r212279
[Bug sanitizer/61693] [asan] is not intercepting aligned_alloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61693 Kostya Serebryany changed: What|Removed |Added CC||eugeni.stepanov at gmail dot com, ||glider at google dot com, ||timu at google dot com --- Comment #4 from Kostya Serebryany --- http://llvm.org/viewvc/llvm-project?view=revision&revision=212322 implements aligned_alloc support on Linux. I will let others implement Android/Windows/Mac support if relevant. This will reach GCC with the next libsanitizer merge (not sure when), or feel free to cherry pick in a couple of days (to make sure it works well)
[Bug sanitizer/61693] [asan] is not intercepting aligned_alloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61693 --- Comment #3 from Kostya Serebryany --- yep, that's the plan...
[Bug sanitizer/61693] [asan] is not intercepting aligned_alloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61693 Kostya Serebryany changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-07-04 Assignee|unassigned at gcc dot gnu.org |kcc at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Kostya Serebryany --- Interesting. This is a relatively new c11 feature. On older Linux distros this does not compile nor link: aligned_alloc.c: In function ‘main’: aligned_alloc.c:5:3: warning: implicit declaration of function ‘aligned_alloc’ [-Wimplicit-function-declaration] void * p = aligned_alloc(128, 1024); ... /tmp/ccJJcsqx.o: In function `main': aligned_alloc.c:(.text+0x13): undefined reference to `aligned_alloc' On Ubuntu 14.04 it behaves as you describe and indeed we need to add an interceptor. The tricky part is to add a test that will work on older distros
[Bug sanitizer/61547] Invalid sanitization of trailing byte in __builtin_strlen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61547 --- Comment #4 from Kostya Serebryany --- (In reply to Richard Biener from comment #3) > (In reply to Kostya Serebryany from comment #2) > > Note that in clang we chose not to instrument any builtins in compiler, > > but instead fully rely on interceptors. > > So you never expand such builtins inline? Not that I know of. LLVM has only 3 builtins like this (memset/memcpy/memmove): http://llvm.org/docs/LangRef.html#standard-c-library-intrinsics And asan replaces these builtins with asan's own call (e.g. __asan_memset)
[Bug sanitizer/61547] Invalid sanitization of trailing byte in __builtin_strlen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61547 --- Comment #2 from Kostya Serebryany --- Note that in clang we chose not to instrument any builtins in compiler, but instead fully rely on interceptors.
[Bug sanitizer/61408] r205695 breaks packaging step of Firefox 24 ESR on Ubuntu Lucid building with ASan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61408 --- Comment #12 from Kostya Serebryany --- I am not sure what does your bisection of LLVM/clang/compiler-rt mean if you say that clang trunk works fine.
[Bug sanitizer/61475] Building Firefox with ASan is broken in the packaging step
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61475 --- Comment #6 from Kostya Serebryany --- So, clang trunk works and gcc trunk fails, right? Could be a miscompile by GCC. I'd suggest to find the guilty module somehow (e.g. build all modules w/ and w/o asan and then mix them in different proportions until you have just one asan-ified module and FF still fails). (I may not get to reproducing this myself any time soon, sorry)
[Bug sanitizer/61475] Building Firefox with ASan is broken in the packaging step
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61475 --- Comment #1 from Kostya Serebryany --- Please 1. try building with -static-libasan 2. provide full reproduction steps
[Bug sanitizer/61408] r205695 breaks packaging step of Firefox 24 ESR on Ubuntu Lucid building with ASan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61408 --- Comment #4 from Kostya Serebryany --- > > LLVM trunk? > > Have not tried yet. Shall I? asan is being developed in LLVM trunk. So if there is a bug in run-time it's better to investigate the freshest variant in LLVM trunk The fix will have to go there first anyway. If the problem is in GCC instrumentation, then of course, there is no reason to test LLVM. But you say that the problem stared after the libsanitizer merge, so it is likely in run-time. It can be a problem in FF itself or in the way you run it, of course.
[Bug sanitizer/61408] r205695 breaks packaging step of Firefox 24 ESR on Ubuntu Lucid building with ASan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61408 --- Comment #2 from Kostya Serebryany --- Does this happen with GCC trunk? LLVM trunk?
[Bug sanitizer/61293] asan can not find left buffer overflow of new[]-allocated buffer, frontend help needed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61293
--- Comment #2 from Kostya Serebryany ---
(In reply to Jakub Jelinek from comment #1)
> IMNSHO you can't change the value of extra, that is an ABI issue,
> and -fsanitize=address shouldn't be an ABI changing option. Consider:
> struct S { S (); ~S (); };
> S *foo (int n) { return new S[n]; }
> void bar (S *p) { delete [] p; }
> int main () { bar (foo (5)); }
> where bar is defined in a different compilation unit/library and something
> is built with -fsanitize=address, something is not.
>
> If the padding before structure is at least 64-bit, sure, instrumenting the
> FE to put there an __asan_poison_memory_region call after the size is stored
yep
> there
> and in delete[] again to __asan_unpoison_memory_region before reading the
> size should not be that hard.
Yes, but a bit more preferable is to ignore the instructions
reading the size instead of calling __asan_unpoison_memory_region.
Consider a case where the DTORs are accessing the array itself out of bounds.
(We've seen similar things!!)
That's a bit harder to implement though.
>
> For 32-bit code if the type doesn't need at least 64-bit alignment (again,
> alignment of the type is an ABI thing), you are out of luck I'm afraid.
Yea... We can theoretically request operator new to
return memory that is == 4 mod 8 for these cases.
That's a bit complicated too...
> Thus, e.g. tests for this will need to be conditionalized.
[Bug sanitizer/61293] New: asan can not find left buffer overflow of new[]-allocated buffer, frontend help needed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61293 Bug ID: 61293 Summary: asan can not find left buffer overflow of new[]-allocated buffer, frontend help needed Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: kcc at gcc dot gnu.org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, timu at google dot com asan does not detect the following case: TypeWithDtor *a = new TypeWithDtor[N]; a[-1] = ... https://code.google.com/p/address-sanitizer/issues/detail?id=314 That's because when we have new[] for a type with DTORs, the actual allocated size is greater. The code looks something like this: extra = max(sizeof(long), alignment_of(TypeWithDtor)); ptr = malloc(N + extra); *(long*)(ptr+extra-sizeof(long)) = N; return ptr + extra; // must be properly aligned for TypeWithDtor As the result, we will not detect overwrites of new[] cookie -- scary! I don't see how we can implement this w/o help from FE. First, we need to ensure alignment 8 even on 32-bits: extra = max(8, alignment_of(TypeWithDtor)); Second, we need to poison the first extra bytes. Lastly, we need to not instrument the legitimate loads/stores of the cookie generated by the frontend. All of this has to be done with the help from FE
[Bug sanitizer/61100] asan/tsan should have the sanitizer includes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61100 Kostya Serebryany changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Kostya Serebryany --- Excellent, thank you!
[Bug sanitizer/61095] [4.10 Regression] miscompile: tsan is broken in gcc trunk, works in 4.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61095
--- Comment #11 from Kostya Serebryany ---
ignore comment #9, everything seems to work now.
This passes:
make -j 40 -C gcc check-g{cc,++}
RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} tsan.exp'
[Bug sanitizer/61095] [4.10 Regression] miscompile: tsan is broken in gcc trunk, works in 4.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61095 --- Comment #10 from Kostya Serebryany --- also, just curious: are such fixes supposed to be accompanied with regression tests?
[Bug sanitizer/61095] [4.10 Regression] miscompile: tsan is broken in gcc trunk, works in 4.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61095 --- Comment #9 from Kostya Serebryany --- I confirm that the minimized reproducer is fixed, but tsan is still crashing on the same CHECK: ../gcc-inst/bin/g++ -g -fsanitize=thread -fPIE -pie -static-libtsan simple_race.cc && ./a.out FATAL: ThreadSanitizer CHECK failed: ../../../../gcc/libsanitizer/tsan/tsan_rtl.cc:587 "((IsShadowMem((uptr)(p + size * kShadowCnt / kShadowCell - 1 != (0)" (0x0, 0x0) #0 __tsan::PrintCurrentStackSlow() ../../../../gcc/libsanitizer/tsan/tsan_rtl_report.cc:710 (a.out+0x0005840c) #1 __tsan::TsanCheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) ../../../../gcc/libsanitizer/tsan/tsan_rtl_report.cc:39 (a.out+0x000584e2) #2 __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_common.cc:74 (a.out+0x0005ea93) #3 MemoryRangeSet ../../../../gcc/libsanitizer/tsan/tsan_rtl.cc:587 (a.out+0x0001e1d6) Maybe there is another similar issue somewhere nearby
[Bug sanitizer/61100] New: asan/tsan should have the sanitizer includes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61100 Bug ID: 61100 Summary: asan/tsan should have the sanitizer includes Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: kcc at gcc dot gnu.org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org asan/tsan users may need to use the tool's API that is defined in headers like I.e. the directory libsanitizer/include/sanitizer should be installed together with the rest of the gcc so that is a valid include path
[Bug sanitizer/61095] [4.10 Regression] miscompile: tsan is broken in gcc trunk, works in 4.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61095 Kostya Serebryany changed: What|Removed |Added Target||x86_64-*-* Target Milestone|--- |4.10.0 Summary|miscompile: tsan is broken |[4.10 Regression] |in gcc trunk, works in 4.9 |miscompile: tsan is broken ||in gcc trunk, works in 4.9
[Bug sanitizer/61095] miscompile: tsan is broken in gcc trunk, works in 4.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61095
Kostya Serebryany changed:
What|Removed |Added
Target|x86_64-*-* |
Priority|P3 |P1
Target Milestone|4.10.0 |---
Summary|[4.10 Regression] tsan is |miscompile: tsan is broken
|broken in gcc trunk, works |in gcc trunk, works in 4.9
|in 4.9 |
--- Comment #2 from Kostya Serebryany ---
fresh gcc optimizes away a piece of code. minimal repro:
int FOO(unsigned long addr) {
unsigned long *p = (unsigned long*)((addr & 0x83f8UL) * 4);
unsigned long xxx = (unsigned long)(p + 1);
return xxx >= 0x3c0UL;
}
gcc 4.9:
/usr/local/gcc-4.9.0/bin/gcc -S z.c -O2 -o - | grep -A 10 FOO:
FOO:
.LFB0:
.cfi_startproc
movabsq $-136339441844232, %rax
andq%rax, %rdi
movabsq $4123168604159, %rax
leaq8(,%rdi,4), %rdx
cmpq%rax, %rdx
seta%al
movzbl %al, %eax
ret
trunk:
../gcc-inst/bin/gcc -S z.c -O2 -o - | grep -A 10 FOO:
FOO:
.LFB0:
.cfi_startproc
xorl%eax, %eax
ret
[Bug sanitizer/61095] tsan is broken in gcc trunk, works in 4.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61095
--- Comment #1 from Kostya Serebryany ---
I suspect a miscompile,
at least the following patch to the libsanitizer sources fixes the problem:
--- tsan_rtl.cc (revision 210145)
+++ tsan_rtl.cc (working copy)
@@ -584,7 +584,8 @@
if (kGoMode || size < 64*1024) {
u64 *p = (u64*)MemToShadow(addr);
CHECK(IsShadowMem((uptr)p));
-CHECK(IsShadowMem((uptr)(p + size * kShadowCnt / kShadowCell - 1)));
+volatile uptr xxx = (uptr)(p + size * kShadowCnt / kShadowCell - 1);
+CHECK(IsShadowMem(xxx));
// FIXME: may overwrite a part outside the region
for (uptr i = 0; i < size / kShadowCell * kShadowCnt;) {
p[i++] = val;
Note the "volatile". W/o volatile tsan still crashes.
[Bug sanitizer/61095] New: tsan is broken in gcc trunk, works in 4.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61095
Bug ID: 61095
Summary: tsan is broken in gcc trunk, works in 4.9
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: kcc at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
tsan seems to be broken in the current gcc trunk
(Tested r210145 on Linux ubuntu 12.04).
gcc 4.9.0 works fine.
There have been no recent libsanitizer merges from upstream so the problem
was likely introduced somewhere in the buildfiles, etc
% /usr/local/gcc-4.9.0/bin/g++ -g -fsanitize=thread -fPIE -pie -static-libtsan
simple_race.cc && ./a.out
==
WARNING: ThreadSanitizer: data race (pid=31025)
...
% ../gcc-inst/bin/g++ -g -fsanitize=thread -fPIE -pie -static-libtsan
simple_race.cc && ./a.out
FATAL: ThreadSanitizer CHECK failed:
../../../../gcc/libsanitizer/tsan/tsan_rtl.cc:587 "((IsShadowMem((uptr)(p +
size * kShadowCnt / kShadowCell - 1 != (0)" (0x0, 0x0)
#0 __tsan::PrintCurrentStackSlow()
../../../../gcc/libsanitizer/tsan/tsan_rtl_report.cc:710 (a.out+0x0005840c)
#1 __tsan::TsanCheckFailed(char const*, int, char const*, unsigned long
long, unsigned long long)
../../../../gcc/libsanitizer/tsan/tsan_rtl_report.cc:39 (a.out+0x000584e2)
#2 __sanitizer::CheckFailed(char const*, int, char const*, unsigned long
long, unsigned long long)
../../../../gcc/libsanitizer/sanitizer_common/sanitizer_common.cc:74
(a.out+0x0005ea93)
#3 MemoryRangeSet ../../../../gcc/libsanitizer/tsan/tsan_rtl.cc:587
(a.out+0x0001e1d6)
#4 __tsan::user_alloc(__tsan::ThreadState*, unsigned long, unsigned long,
unsigned long) ../../../../gcc/libsanitizer/tsan/tsan_mman.cc:113
(a.out+0x0005403a)
#5 calloc ../../../../gcc/libsanitizer/tsan/tsan_interceptors.cc:500
(a.out+0x0003d4d4)
#6 _dl_allocate_tls :0 (ld-linux-x86-64.so.2+0x00012074)
#7 __pthread_create_2_1 :0 (libpthread.so.0+0x8abc)
#8 pthread_create
../../../../gcc/libsanitizer/tsan/tsan_interceptors.cc:891
(a.out+0x0003b758)
#9 main /home/kcc/tmp/simple_race.cc:23 (a.out+0x00079473)
#10 __libc_start_main :0 (libc.so.6+0x0002176c)
#11 :0 (a.out+0x00010694)
% cat simple_race.cc
#include
int Global;
void *Thread1(void *x) {
Global++;
return NULL;
}
int main() {
pthread_t t;
pthread_create(&t, NULL, Thread1, NULL);
Global++;
pthread_join(t, NULL);
}
%
[Bug other/61016] use of uninitialized memory in gcc/config/i386/i386.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61016 Kostya Serebryany changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #2 from Kostya Serebryany --- "svn blame" tells that the uninitialized array was introduced by hubicka@: 45726hubicka enum x86_64_reg_class subclasses[MAX_CLASSES];
[Bug other/61016] use of uninitialized memory in gcc/config/i386/i386.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61016
--- Comment #1 from Kostya Serebryany ---
Slightly more reduced test:
template
struct vector {
void resize(int, T = T()) {}
};
class UnknownField;
class UnknownFieldSet {
void DeleteByNumber (int);
vector < UnknownField > *fields_;
};
class UnknownField {
long a;
union {
void *b;
};
};
void UnknownFieldSet::DeleteByNumber (int) {
fields_->resize (0);
}
[Bug sanitizer/61021] [4.9 regression] libsanitizer fails to build with old glibc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61021 --- Comment #1 from Kostya Serebryany --- Please send the patch to llvm-commits, we'll review it and apply it upstream (We may not be able to do so before ~ May 5). Then you can either wait for the next merge (we planned it for ~ mid May, but it may take quite some time), or send it directly to gcc-patches >> the minimum kernel/glibc requirements for libsanitizer need to be documented >> and enforced by the configure scripts if possible. I thought this was done. Jakub?
[Bug other/61016] New: use of uninitialized memory in gcc/config/i386/i386.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61016
Bug ID: 61016
Summary: use of uninitialized memory in gcc/config/i386/i386.c
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: kcc at gcc dot gnu.org
CC: eugeni.stepanov at gmail dot com
Created attachment 32715
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32715&action=edit
z.cc
This is revision 209930 on x86_64 Linux.
% valgrind --track-origins=yes gcc/cc1plus -quiet z.cc-O2 -o /dev/null
==12029== Conditional jump or move depends on uninitialised value(s)
==12029==at 0xDBEF66: classify_argument(machine_mode, tree_node const*,
x86_64_reg_class*, int) (gcc/config/i386/i386.c:6361)
==12029==by 0xDBF2D4: classify_argument(machine_mode, tree_node const*,
x86_64_reg_class*, int) (gcc/config/i386/i386.c:6501)
==12029==by 0xDBA097: ix86_function_arg_advance(cumulative_args_t,
machine_mode, tree_node const*, bool) (gcc/config/i386/i386.c:6818)
==12029==by 0x92B40A: gimplify_parameters() (gcc/function.c:3624)
==12029==by 0x978AEA: gimplify_body(tree_node*, bool) (gcc/gimplify.c:8620)
==12029==by 0x9794AC: gimplify_function_tree(tree_node*)
(gcc/gimplify.c:8777)
==12029==by 0x7EBC14: analyze_function(cgraph_node*) (gcc/cgraphunit.c:649)
==12029==by 0x7EECD2: analyze_functions() (gcc/cgraphunit.c:1017)
==12029==by 0x7EEACB: finalize_compilation_unit() (gcc/cgraphunit.c:2320)
==12029==by 0x5E67D3: cp_write_global_declarations() (gcc/cp/decl2.c:4619)
==12029==by 0xB19A20: compile_file() (gcc/toplev.c:562)
==12029==by 0xB197D7: toplev_main(int, char**) (gcc/toplev.c:1914)
==12029== Uninitialised value was created by a stack allocation
==12029==at 0xDBE920: classify_argument(machine_mode, tree_node const*,
x86_64_reg_class*, int) (gcc/config/i386/i386.c:6412)
The bug was initially detected by MemorySanitizer (which is a bit trickier to
use with gcc at the moment)
==5348== WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x7f265400f64d in merge_classes(x86_64_reg_class, x86_64_reg_class)
gcc/config/i386/i386.c:6361
#1 0x7f265400f64d in classify_argument(machine_mode, tree_node const*,
x86_64_reg_class*, int) gcc/config/i386/i386.c:6557
#2 0x7f265400dbfa in classify_argument(machine_mode, tree_node const*,
x86_64_reg_class*, int) gcc/config/i386/i386.c:6501
#3 0x7f2653fef8fc in examine_argument(machine_mode, tree_node const*, int,
int*, int*) gcc/config/i386/i386.c:6817
#4 0x7f2653fef8fc in function_arg_advance_64(ix86_args*, machine_mode,
tree_node const*, long, bool) gcc/config/i386/i386.c:7199
#5 0x7f2653fef8fc in ix86_function_arg_advance(cumulative_args_t,
machine_mode, tree_node const*, bool) gcc/config/i386/i386.c:7253
#6 0x7f26523a1ae1 in gimplify_parameters() gcc/function.c:3624
#7 0x7f2652594737 in gimplify_body(tree_node*, bool) gcc/gimplify.c:8620
#8 0x7f2652598479 in gimplify_function_tree(tree_node*) gcc/gimplify.c:8777
#9 0x7f2651bee7db in analyze_function(cgraph_node*) gcc/cgraphunit.c:649
#10 0x7f2651c01aa1 in analyze_functions() gcc/cgraphunit.c:1017
#11 0x7f2651c01088 in finalize_compilation_unit() gcc/cgraphunit.c:2320
#12 0x7f2650f8da6e in cp_write_global_declarations() gcc/cp/decl2.c:4619
#13 0x7f2652fa249d in compile_file() gcc/toplev.c:562
#14 0x7f2652fa06ff in do_compile() gcc/toplev.c:1914
#15 0x7f2652fa06ff in toplev_main(int, char**) gcc/toplev.c:1990
#16 0x7f26552563b3 in main gcc/main.c:36
#17 0x7f264f30276c in __libc_start_main
/build/buildd/eglibc-2.15/csu/libc-start.c:226
#18 0x7f26509f8960 in _start
(/usr/local/google/ssd/msan-gcc/inst/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/cc1plus+0x2f4960)
Uninitialized value was created by an allocation of 'subclasses' in the stack
frame of function 'classify_argument(machine_mode, tree_node const*,
x86_64_reg_class*, int)'
#0 0x7f265400a310 in classify_argument(machine_mode, tree_node const*,
x86_64_reg_class*, int) gcc/config/i386/i386.c:6412
Confirmed by printf:
Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c (revision 209930)
+++ gcc/config/i386/i386.c (working copy)
@@ -6428,6 +6428,7 @@
int i;
tree field;
enum x86_64_reg_class subclasses[MAX_CLASSES];
+ subclasses[1] = (enum x86_64_reg_class)0xab;
/* On x86-64 we pass structures larger than 64 bytes on the stack. */
if (bytes > 64)
@@ -6553,8 +6554,10 @@
bit_offset);
if (!num)
return 0;
- for (i = 0; i < num; i++)
+ for (i = 0; i < num; i++) {
+fprintf(
[Bug sanitizer/60861] out of bounds access of global var in .rodata/.bss not detected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60861 Kostya Serebryany changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #6 from Kostya Serebryany --- None of these is an asan bug, closing. Feel free to reopen if you disagree.
[Bug sanitizer/60861] out of bounds access of global var in .rodata/.bss not detected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60861 --- Comment #1 from Kostya Serebryany --- Will adding "-fno-common" help? Or building the test as C++? See https://code.google.com/p/address-sanitizer/wiki/Flags
[Bug sanitizer/60536] Backtrace corrupted on Firefox build with -fsanitize=address and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60536 --- Comment #13 from Kostya Serebryany --- > What about the "allocating memory until the OOM killer hits" issue? > Do you think this is an asan bug? Dunno. File a bug with more details if you think it's a bug. I guess you can close this one.
[Bug sanitizer/60536] Backtrace corrupted on Firefox build with -fsanitize=address and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60536 --- Comment #11 from Kostya Serebryany --- > Sorry, but I don't have a google account and refuse to create one. You can login to our bug tracker with any existing e-mail, or you can contact us via address-saniti...@googlegroups.com or you can file a bug using the llvm bug tracker
[Bug sanitizer/60536] Backtrace corrupted on Firefox build with -fsanitize=address and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60536 --- Comment #10 from Kostya Serebryany --- > ==10632==ERROR: AddressSanitizer: heap-use-after-free on address > 0x6021ec50 at pc 0x7f3e30645dbd bp 0x7fff6d3b2a60 sp 0x7fff6d3b2a38 > READ of size 2 at 0x6021ec50 thread T0 > #0 0x7f3e30645dbc in setlocale So, sounds like a real use-after-free in firefox
[Bug sanitizer/60536] Backtrace corrupted on Firefox build with -fsanitize=address and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60536 --- Comment #6 from Kostya Serebryany --- > _Unwind_Find_FDE+0x01D9 /home/markus/gcc/libgcc/unwind-dw2-fde-dip.c:462 > /home/markus/gcc/libgcc/unwind-dw2.c:1182 > _Unwind_Backtrace+0x004B /home/markus/gcc/libgcc/unwind.inc:291 Interesting. asan detects a bug and starts reporting it, then if crashes inside the slow unwinder. Try the fast unwinder? ASAN_OPTIONS=fast_unwind_on_fatal=1
[Bug sanitizer/60536] Backtrace corrupted on Firefox build with -fsanitize=address and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60536 --- Comment #5 from Kostya Serebryany --- > Clang trunk cannot build Firefox with -fsanitize=address, because I get > asan related linker errors. To the best of my knowledge, firefox is routinely built by several different teams using clang+asan. Please report a separate bug at code.google.com/p/address-sanitizer/
[Bug sanitizer/60536] Backtrace corrupted on Firefox build with -fsanitize=address and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60536 --- Comment #2 from Kostya Serebryany --- Please symbolize the output. Also, does this happen with the clang version of AddressSanitizer?
[Bug sanitizer/60038] AddressSanitizer CHECK failed ... "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" on CentOS 5.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60038 --- Comment #14 from Kostya Serebryany --- Landed upstream: http://llvm.org/viewvc/llvm-project?view=revision&revision=200733 Note that the patch is slightly different from Jakub's: it uses memory_order_relaxed. My understanding is that now is not the best time to do full merge from upstream, so feel free to commit this patch to GCC separately.
[Bug sanitizer/60038] AddressSanitizer CHECK failed ... "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" on CentOS 5.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60038 --- Comment #8 from Kostya Serebryany --- (In reply to Jakub Jelinek from comment #6) > size_t len = confstr (_CS_GNU_LIBC_VERSION, buf, sizeof buf); > if (strncmp (buf, "glibc 2.", 8) == 0) Yea, such patch is even more welcome. I was thinking about using __gnu_get_libc_version, to extract the libc version numbers, but confstr (_CS_GNU_LIBC_VERSION sounds good too.
[Bug sanitizer/60038] AddressSanitizer CHECK failed ... "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" on CentOS 5.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60038 --- Comment #5 from Kostya Serebryany --- > We probably just have to fill in correct values for glibc 2.5. This may help. A patch is welcome, please check https://code.google.com/p/address-sanitizer/wiki/HowToContribute
[Bug sanitizer/60038] AddressSanitizer CHECK failed ... "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" on CentOS 5.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60038 --- Comment #4 from Kostya Serebryany --- > GNU C Library stable release version 2.5 2.5 is way too old. You may try to comment out this CHECK and see if the rest works The main ASAN's functionality will probably not notice the lack of correct data about TLS, but LSAN (LeakSanitizer) may start reporting false positives.
[Bug sanitizer/60038] AddressSanitizer CHECK failed ... "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" on CentOS 5.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60038 --- Comment #1 from Kostya Serebryany --- I expect this also happens with the clang version of ASAN, please confirm. This is related to the hackish way we extract stack and tls bounds, and CentOS 5.10 may have different version of glibc or some other difference. What is the version of glibc on your OS? We are trying to solve it in a general way in glibc (https://sourceware.org/bugzilla/show_bug.cgi?id=16291), but that will not happen for the existing distros.
[Bug sanitizer/59733] [4.9 Regression] bootstrap-asan failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733 Kostya Serebryany changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |WONTFIX --- Comment #25 from Kostya Serebryany --- Even with this workaround asan is almost unusable with the buggy kernel. I suspect that when a process has too many mappings it gets too slow. The machine where we have our clang-asan bootstrap gets very slow and unreliable. We have reverted the kernel on that bot (http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/) and reverted the above workaround in llvm trunk. http://llvm.org/viewvc/llvm-project?rev=200217&view=rev The kernel fix went into Linus's tree for 3.14 last week, and was tagged for stable backport. Nothing else we could do here.
[Bug sanitizer/59733] [4.9 Regression] bootstrap-asan failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
Kostya Serebryany changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |kcc at gcc dot gnu.org
Target Milestone|4.9.0 |---
--- Comment #24 from Kostya Serebryany ---
I increased the mmap granularity in sanitizer's allocator to
allow our bot on ubuntu pre-14.04 to pass.
http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/sanitizer_common/sanitizer_allocator.h?r1=200197&r2=200196&pathrev=200197
Feel free to apply the same change to GCC trunk.
Once the kernel bug is fixed and the fix reaches ubuntu 14.04 tree
we will likely revert this change.
There is nothing else we can do on sanitizer side -- the kernel bug
is significant (e.g. it makes gimp crash) and so such system is unusable
for many other purposes.
Let's keep this bug open so that we don't forget to revert the workaround.
FTR, here is a program that detects the presence of a broken kernel:
#include
#include
#include
#include
#include
int main() {
char *p = (char*)0x6000;
size_t i;
for (i = 0; i < 10; i++) {
void *addr = p + i * 4096;
void *ret = mmap(addr, 4096, PROT_WRITE | PROT_READ,
MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
if (addr != ret) {
fprintf(stderr, "failed at iteration %zd\n", i);
char command[100];
snprintf(command, sizeof(command), "cat /proc/%d/maps | head -30",
getpid());
system(command);
return 1;
}
}
}
On a broken kernel it will print something like this:
failed at iteration 65514
0040-00401000 r-xp fc:00 20991316 /tmp/a.out
0060-00601000 r--p fc:00 20991316 /tmp/a.out
00601000-00602000 rw-p 1000 fc:00 20991316 /tmp/a.out
6000-60001000 rw-p 00:00 0
60001000-60002000 rw-p 00:00 0
60002000-60003000 rw-p 00:00 0
60003000-60004000 rw-p 00:00 0
60004000-60005000 rw-p 00:00 0
...
[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309 --- Comment #58 from Kostya Serebryany --- FTR, here are the new numbers; except for 464.h264ref looks good. clang r199888, gcc r207025 flags: -O2 -fsanitize=address machine: Dell 3500 (Intel(R) Xeon(R) CPU W3690 @ 3.47GHz) clang gccdiff 400.perlbench, 1286.00,-1.00,-0.00 401.bzip2, 857.00, 940.00, 1.10 403.gcc, 621.00, 606.00, 0.98 429.mcf, 578.00, 574.00, 0.99 445.gobmk, 860.00, 850.00, 0.99 456.hmmer, 880.00, 1149.00, 1.31 458.sjeng, 992.00, 996.00, 1.00 462.libquantum, 492.00, 483.00, 0.98 464.h264ref, 1274.00, 3998.00, 3.14 471.omnetpp, 566.00, 569.00, 1.01 473.astar, 661.00, 647.00, 0.98 483.xalancbmk, 478.00, 491.00, 1.03 433.milc, 620.00, 611.00, 0.99 444.namd, 601.00, 528.00, 0.88 447.dealII, 624.00, 670.00, 1.07 450.soplex, 366.00, 389.00, 1.06 453.povray, 430.00, 374.00, 0.87 470.lbm, 355.00, 452.00, 1.27 482.sphinx3, 926.00, 1108.00, 1.20
[Bug sanitizer/59733] [4.9 Regression] bootstrap-asan failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733 --- Comment #23 from Kostya Serebryany --- Relevant Kernel bug: https://bugzilla.kernel.org/show_bug.cgi?id=67651
[Bug sanitizer/59733] [4.9 Regression] bootstrap-asan failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733 --- Comment #22 from Kostya Serebryany --- A quick workaround would be to change static const uptr kUserMapSize = 1 << 16; in sanitizer_common/sanitizer_allocator.h to something like 17 or 18. We can also try using mremap. However I'd like to hear from kernel experts whether this is considered a kernel bug or a feature.
[Bug sanitizer/59733] [4.9 Regression] bootstrap-asan failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733 --- Comment #19 from Kostya Serebryany --- (In reply to Kostya Serebryany from comment #18) > eugenis@ says he sees something similar on Ubuntu 13.10. Actually, only on Ubuntu 14.04 candidate. Looks like a fresh regression in Kernel.
[Bug sanitizer/59733] [4.9 Regression] bootstrap-asan failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733 Kostya Serebryany changed: What|Removed |Added CC||eugeni.stepanov at gmail dot com --- Comment #18 from Kostya Serebryany --- eugenis@ says he sees something similar on Ubuntu 13.10.
