https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79099
Kostya Serebryany changed:
What|Removed |Added
CC||kcc at gcc dot gnu.org
--- Comment
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
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)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78028
--- Comment #1 from Kostya Serebryany ---
interestingly, this works for me with clang
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
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
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
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
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.
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
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 v
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
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67168
Kostya Serebryany changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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,
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,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65285
Kostya Serebryany changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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 believ
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 -sta
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,
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 -fsan
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
%
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
> +++ libsa
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-san
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 :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
Kostya Serebryany changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
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 cod
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 t
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
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.
>
> B
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 ?
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 ob
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
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 over
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 upstre
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 di
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
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 s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63927
Kostya Serebryany changed:
What|Removed |Added
CC||eugeni.stepanov at gmail dot
com,
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 v
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
>
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,
b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63418
--- Comment #3 from Kostya Serebryany ---
Thanks for confirming the current state of this warning :)
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
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 mod
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
,
||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/c
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
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
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 wil
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
black
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 u
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
---
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
||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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61693
Kostya Serebryany changed:
What|Removed |Added
CC||eugeni.stepanov at gmail dot
com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61693
--- Comment #3 from Kostya Serebryany ---
yep, that's the plan...
||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
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 in
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.
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.
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 propor
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
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 t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61408
--- Comment #2 from Kostya Serebryany ---
Does this happen with GCC trunk?
LLVM trunk?
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 ();
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61100
Kostya Serebryany changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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'
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?
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: Threa
: 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 th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61095
Kostya Serebryany changed:
What|Removed |Added
Target||x86_64-*-*
Target Milestone|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61095
Kostya Serebryany changed:
What|Removed |Added
Target|x86_64-*-* |
Priority|P3
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 || s
: 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61016
Kostya Serebryany changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Commen
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_;
};
cl
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 m
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_6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60861
Kostya Serebryany changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
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.
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 fil
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 0x7f3e30
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
Interestin
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.
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?
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 no
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 thinki
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
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 d
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 o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
Kostya Serebryany changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
|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/com
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)
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
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
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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
Kostya Serebryany changed:
What|Removed |Added
CC||eugeni.stepanov at gmail dot
com
---
1 - 100 of 294 matches
Mail list logo
