http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #25 from Dmitry Vyukov 2013-02-07
17:18:05 UTC ---
On Thu, Feb 7, 2013 at 9:00 PM, jakub at gcc dot gnu.org
wrote:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
>
> --- Comment #24 from Jakub Jelinek 2013-02-07
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #35 from Dmitry Vyukov 2013-02-12
08:47:21 UTC ---
On Tue, Feb 12, 2013 at 12:39 PM, jakub at gcc dot gnu.org
wrote:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
>
> --- Comment #34 from Jakub Jelinek 2013-02-12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57507
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment #3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #41 from Dmitry Vyukov ---
Similar problem with libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57507
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59188
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment #3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59188
--- Comment #4 from Dmitry Vyukov ---
> glibc (at least the 2.17 I have around) doesn't have sigsetjmp function at all
this must be fine, we do not call it if it's not used
> Not to mention that the arguments are wrong even for __sigsetjmp
setj
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59188
--- Comment #6 from Dmitry Vyukov ---
Great, thanks!
I will prepare a real patch.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59188
--- Comment #7 from Dmitry Vyukov ---
I've committed the fix into llvm:
http://llvm.org/viewvc/llvm-project?view=revision&revision=195345
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment #9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #2 from Dmitry Vyukov ---
It seems that this kernel has ASLR disabled, so kernel maps libraries at 0x55.
Tsan does not support this ATM.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #13 from Dmitry Vyukov ---
And what if you enable randomization?
> Have any attempt for saner tsan shadow memory mapping be done in the last
> year?
No, there were no such attempts.
But, yes, it would be nice if tsan supports no-ASR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51521
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85310
--- Comment #6 from Dmitry Vyukov ---
It seems to me that compiler is fine here and we just have a bug in kernel
code.
Result of strlen called on char[16] can't possibly by >15 (without causing
undefined behavior -- reading past the end of the ob
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #6 from Dmitry Vyukov ---
Right!
Unpoisoning before restoring SP looks like a reasonable and simple solution to
me. I don't see any potential downsides.
Do you mind submitting a fix for this?
Thanks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #8 from Dmitry Vyukov ---
Depending on how long the proper fix will take. If we are talking about, say, a
week then I will just wait. We have to deal with hundreds of assorted kernel
crashes all over the place anyway.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #12 from Dmitry Vyukov ---
When/if you have a patch I can test it on kernel.
But seems this is a problem for user-space too. We just need a large alloca +
signal handlers, or dirty manual SP manipulations (like we have in tsan to
imp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #16 from Dmitry Vyukov ---
Here is disasm of the function with the patch:
https://gist.githubusercontent.com/dvyukov/e9dca961ceb436049cf5881b3307b104/raw/05ed3daff60d00eb71ca7a85be707d6d5eca3c47/gistfile1.txt
And the epilogue:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #19 from Dmitry Vyukov ---
When I am trying to build anything with -g on a machine with binutils 2.26.1 I
am getting:
/tmp/ccTFsPnM.s: Assembler messages:
/tmp/ccTFsPnM.s:11: Error: unknown .loc sub-directive `view'
/tmp/ccTFsPnM.s:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #21 from Dmitry Vyukov ---
I guess it just used my system binutils. Used to work before.
I now used an older distribution to build it. Seems to work.
: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: dvyukov at google dot com
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, marxin at
gcc dot gnu.org
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90746
--- Comment #3 from Dmitry Vyukov ---
> It would probably useful to have __attribute__((notailcall)) which the
> sanitizers then could stick on the function types.
It should be on _declaration_, right? Sanitizers only provide a definition. The
: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: dvyukov at google dot com
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, marxin at
gcc dot gnu.org
Target Milestone: ---
We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #1 from Dmitry Vyukov ---
I am also looking at kernel callback implementation, maybe they disagree with
compiler as to what's actually passed as arguments:
/* Emitted by compiler to poison alloca()ed objects. */
void __asan_alloca_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #2 from Dmitry Vyukov ---
The runtime callbacks look correct to me, and the shadow they produce also
looks reasonable: 32-byte rezone before, 32 + (32 - object size) redzone after:
8800247b7180: 00 00 00 00 00 00 00 00 00 00 00
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #3 from Dmitry Vyukov ---
Hummm, perhaps gcc expects that the left ASAN redzone will be within the
128-byte ABI redzone, but this becomes false with -mno-red-zone?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #4 from Dmitry Vyukov ---
Removing these lines from runtime does not help unfortunately:
- kasan_poison_shadow(left_redzone, KASAN_ALLOCA_REDZONE_SIZE,
- KASAN_ALLOCA_LEFT);
The right redzone is also someho
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354
--- Comment #2 from Dmitry Vyukov 2012-11-16
17:20:43 UTC ---
> Not much better performance.
Sole -fPIE vs -fPIC gives us 20% speedup on real programs. Indirect call will
add another 10%.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354
--- Comment #17 from Dmitry Vyukov 2012-11-19
10:53:04 UTC ---
>When building libtsan as a shared library (for which I had to hack our assembly
>blobs a bit) we get two sources of slowdown:
> 1. __tsan_read8 and friends are called throug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354
--- Comment #18 from Dmitry Vyukov 2012-11-21
07:45:20 UTC ---
(In reply to comment #17)
> >When building libtsan as a shared library (for which I had to hack our
> >assembly
> >blobs a bit) we get two sources of slowdown:
> > 1. __tsa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354
--- Comment #20 from Dmitry Vyukov 2012-11-21
09:04:07 UTC ---
(In reply to comment #19)
> (In reply to comment #18)
> > For actual ThreadSanitizer runtime -fPIC -ftls-model=initial-exec causes
> > degradation of generated code. Linker em
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55439
Bug #: 55439
Summary: ThreadSanitizer: handle atomic operations
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55439
--- Comment #1 from Dmitry Vyukov 2012-11-22
07:54:47 UTC ---
In the other compiler function-scope statics are lowered to inline code that
includes acquire-load atomic operation. So the interception is critical to not
produce false positiv
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55441
Bug #: 55441
Summary: ThreadSanitizer: handle bitfields
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354
--- Comment #22 from Dmitry Vyukov 2012-11-23
07:16:14 UTC ---
> > For dynamic libraries that are loaded into a non-instrumented executable
> > (e.g.
> > swig so preloaded into python process), we statically link the tsan runtime
> > into
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354
--- Comment #23 from Dmitry Vyukov 2012-11-23
07:27:27 UTC ---
(In reply to comment #21)
> (In reply to comment #20)
> > What I see is that it also affect code generation (register allocation). Do
> > we
> > need to file a bug on that?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354
--- Comment #26 from Dmitry Vyukov 2012-11-23
08:34:52 UTC ---
(In reply to comment #25)
> Have you considered using __builtin_expect to help the compiler in the
> performance sensitive code? Or even better would be profile-feedback, buil
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48076
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48076
--- Comment #6 from Dmitry Vyukov 2012-11-28
03:56:50 UTC ---
There seems to be a similar bug in code generated for function static
variables.
The fast-path load is a plain load rather than atomic acquire load.
On Sat, Nov 24, 2012 at 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #3 from Dmitry Vyukov 2012-12-02
09:35:41 UTC ---
Well, then maybe it will work. But we did not do anything special for Fortran
and OpenMP, and did not do any testing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55521
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #10 from Dmitry Vyukov 2012-12-10
12:57:01 UTC ---
(In reply to comment #9)
> (In reply to comment #8)
> > gfortran -g -fsanitize=thread -fPIC -pie PR55561.f90
>
> Thanks! yields the proper warning as expected..
>
> >
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #12 from Dmitry Vyukov 2012-12-10
15:07:11 UTC ---
(In reply to comment #11)
> (In reply to comment #10)
> > Is is a correct report? Or false positive?
>
> This is a correct report for the testcase in comment #0 (as J is sha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #18 from Dmitry Vyukov 2012-12-29
09:32:53 UTC ---
On Tue, Dec 25, 2012 at 11:30 PM, Joost.VandeVondele at mat dot
ethz.ch wrote:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
>
> --- Comment #15 from Joost VandeVon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #19 from Dmitry Vyukov 2012-12-29
09:38:13 UTC ---
On Wed, Dec 26, 2012 at 12:23 AM, Joost.VandeVondele at mat dot
ethz.ch wrote:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
>
> --- Comment #16 from Joost VandeVon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #20 from Dmitry Vyukov 2012-12-29
10:13:00 UTC ---
(In reply to comment #19)
> On Wed, Dec 26, 2012 at 12:23 AM, Joost.VandeVondele at mat dot
> ethz.ch wrote:
> >
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
> >
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #21 from Dmitry Vyukov 2012-12-29
10:21:06 UTC ---
It is a known issue http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40362#c7
and Jakub said it's safe. I am not that sure.
On Sat, Dec 29, 2012 at 2:13 PM, dvyukov at googl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40362
--- Comment #10 from Dmitry Vyukov 2012-12-29
10:28:06 UTC ---
ThreadSanitizer says the same:
Testcase:
!$OMP PARALLEL PRIVATE(j)
j=OMP_GET_THREAD_NUM()
! no warnings without the dynamic schedule
!$OMP DO SCHEDULE(DYNAMIC,2)
DO i=1,10
ENDDO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40362
--- Comment #12 from Dmitry Vyukov 2012-12-29
12:31:02 UTC ---
(In reply to comment #11)
> (In reply to comment #10)
> > gomp_ptrlock_get() function is not thread-safe. It's not only about
> > atomicity,
> > it's also about memory orderi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40362
--- Comment #14 from Dmitry Vyukov 2012-12-29
22:36:11 UTC ---
(In reply to comment #13)
> (In reply to comment #12)
> > ws = gomp_ptrlock_get (&ws->next_ws);
>
> This is really just:
> ws = gomp_ptrlock_get (ws+offsetof(next_ws));
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #23 from Dmitry Vyukov 2012-12-30
09:57:44 UTC ---
(In reply to comment #22)
> I did do some more testing, and the combination '-fsanitize=thread -fopenmp'
> was really very useful. Apart from the libgomp-related warning discus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #24 from Dmitry Vyukov 2012-12-30
10:11:27 UTC ---
For testing you can comment out first 2 lines of gomp_ptrlock_get(). That
should fix the race in libgomp. It's not a good fix form performance pov, but
should be OK for testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #26 from Dmitry Vyukov 2012-12-30
17:07:01 UTC ---
(In reply to comment #25)
> (In reply to comment #24)
> > For testing you can comment out first 2 lines of gomp_ptrlock_get(). That
> > should fix the race in libgomp. It's no
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #29 from Dmitry Vyukov 2013-01-02
09:09:11 UTC ---
(In reply to comment #28)
> (In reply to comment #26)
> > For config/linux/ptrlock the changes are:
> > [...]
>
> Following your suggestions, I applied the following patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #31 from Dmitry Vyukov 2013-01-02
10:28:00 UTC ---
(In reply to comment #30)
> The formatting in the patch is wrong (multiple issues).
>
> I don't see a point in the __atomic_load_n (addr, MEMMODEL_RELAXED), for
> aligned in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #33 from Dmitry Vyukov 2013-01-08
09:17:31 UTC ---
(In reply to comment #32)
> (In reply to comment #30)
> > The formatting in the patch is wrong (multiple issues).
>
> I've tried to fix them in the version below.
>
> It
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55488
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56128
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #39 from Dmitry Vyukov 2013-02-01
20:00:22 UTC ---
Sorry, I was busy previous weeks. Thanks for fixing this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69624
--- Comment #6 from Dmitry Vyukov ---
Also what gcc version?
I've tried:
gcc version 6.0.0 20160105 (experimental) (GCC)
$ gcc /tmp/af_netlink.c -c -O2 -fsanitize-coverage=trace-pc
-fsanitize=kernel-address --param asan-stack=1 --param asan-glo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69624
--- Comment #8 from Dmitry Vyukov ---
First of all, are you sure that r12 is not 0 before the call?
Deference of 0xdc00 is how KASAN reacts on NULL deref, it does
shadow check before the memory accesses. If original address is NULL,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69624
--- Comment #14 from Dmitry Vyukov ---
Wait, I already disabled instrumentation of hweight.c for because of this:
+# Kernel does not boot if we instrument this file as it uses custom calling
+# convention (see CONFIG_ARCH_HWEIGHT_CFLAGS).
+KCOV_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69624
--- Comment #16 from Dmitry Vyukov ---
> Could you please push that to the syzkaller tree [1] then?
Sorry, syzkaller page referred to outdated patch. I was hoping that Andrew will
take it soon, so that I can update the link to a more respected l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69624
--- Comment #17 from Dmitry Vyukov ---
Jakub, I guess you can close this.
Sorry again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64354
--- Comment #1 from Dmitry Vyukov ---
We've hit this issue while implementing Go support for C++ ThreadSanitizer:
https://github.com/golang/go/issues/14602
__has_feature obviously does not work. Providing __SANITIZE_THREAD__ looks very
reasonable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71042
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64354
--- Comment #3 from Dmitry Vyukov ---
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82116
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78513
--- Comment #6 from Dmitry Vyukov ---
> Then GCC 7 won't build any kernel with KASAN until those kernel patches go in?
Yes.
Kernel passes -fsanitize=kernel-address, some behavior tuning can be done based
on that flag.
Please notify kasan-...@g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77538
--- Comment #21 from Dmitry Vyukov ---
> is that huge number abnormal?
Let's say it is atypical for C/C++ programs because of fixed-size stacks. But
tsan has limit of 64K frames in the latest version (maybe 4.8.2 had limit of
32K frames).
But do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77538
--- Comment #23 from Dmitry Vyukov ---
Please provide disassembly of the function that contains the PC
(__gnu_cxx::__normal_iterator...).
Did we fix any bugs that lead to missed __tsan_func_exit callbacks?
Before we go any deeper, I would sugges
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: dvyukov at google dot com
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
Target Milestone: ---
Created attachment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79944
--- Comment #2 from Dmitry Vyukov ---
I've shutup that bug with dest = NULL, but then I immediately got this:
BUG: KASAN: global-out-of-bounds in clear_bit
include/linux/bitops_compiler.h:15 [inline]
BUG: KASAN: global-out-of-bounds in dma_chann
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79944
--- Comment #3 from Dmitry Vyukov ---
Created attachment 40918
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40918&action=edit
reproducer2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79944
--- Comment #4 from Dmitry Vyukov ---
Attached second minimized reproducer.
Build it with:
gcc dmaengine2.c -fsanitize=address -O2 -lasan -g
It produces:
==57662==ERROR: AddressSanitizer: unknown-crash on address 0x00601321 at pc
0x0040
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79944
--- Comment #6 from Dmitry Vyukov ---
Just build kernel with it. Boots fine and sustains some load now.
Did not do any positive tests, though.
Thanks for the quick fix!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78158
--- Comment #3 from Dmitry Vyukov ---
Also reported on stackoverflow:
http://stackoverflow.com/questions/37552866/why-does-threadsanitizer-report-a-race-with-this-lock-free-example
I've checked with
gcc version 7.0.1 20170307 (experimental) (GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78158
--- Comment #5 from Dmitry Vyukov ---
I may be missing something, but can't we just always emit calls into tsan
runtime under tsan? They accept the memory order value and can work with
constants and runtime values.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78158
--- Comment #8 from Dmitry Vyukov ---
We need to modify tsan runtime to ignore (zero) __ATOMIC_HLE_ACQUIRE/RELEASE
bits, right? It's only an optimization and we can pretend that elision never
succeeds under tsan.
What is sync special bit (0x4000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78158
--- Comment #12 from Dmitry Vyukov ---
I want to land something along the following lines (with proper comments).
Any objections?
Index: tsan_interface_atomic.cc
===
--- tsan_interf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78158
--- Comment #14 from Dmitry Vyukov ---
Right, we need to catch completely bogus values.
But the question is: are these values extending up or down? :)
Because special flag was added after the HLE flags...
So how about 12 bits? :)
--- lib/tsan/r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78158
--- Comment #16 from Dmitry Vyukov ---
Yeah, but before introduction of HLE there were no special flags, and one did
not need to filter at all. And before the sync flag there were no
special-special flags, and one only need to filter 0x. What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78158
--- Comment #18 from Dmitry Vyukov ---
Landed http://llvm.org/viewvc/llvm-project?view=revision&revision=298378 with
0x7fff mask.
Assignee: unassigned at gcc dot gnu.org
Reporter: dvyukov at google dot com
Target Milestone: ---
This pop up in kernel code. We have:
#define __cmpxchg_double(pfx, p1, p2, o1, o2, n1, n2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80148
--- Comment #1 from Dmitry Vyukov ---
Created attachment 41016
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41016&action=edit
source code
The archive contains slub2.c that works, and slub1.c that fails with the error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80148
--- Comment #3 from Dmitry Vyukov ---
> Why doesn't the kernel use atomic builtins instead?
There was a recent discussion here:
https://groups.google.com/forum/#!topic/kasan-dev/3sNHjjb4GCI
In short:
---
Trivially, The C++ model doesn't feature
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68260
--- Comment #4 from Dmitry Vyukov ---
Good point. I wonder if using -O2 fixes this.
We tend to always use tsan with -O2 for performance reasons. Tsan already
considerably slows down execution, and additional unnecessary memory accesses
and non-in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68260
--- Comment #7 from Dmitry Vyukov ---
I looked at the patch, but I am unqualified to review it. The test looks good
to me. +Yuri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77538
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77538
--- Comment #4 from Dmitry Vyukov ---
Unkillable processed in D state usually mean kernel bugs (and there are lots of
them: https://github.com/google/syzkaller/wiki/Found-Bugs).
Please post results of 'cat /proc/PID/task/*/stack` and `cat
/proc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77538
--- Comment #6 from Dmitry Vyukov ---
It hangs trying to dump core file to some pipe:
[] pipe_wait+0x70/0xc0
[] pipe_write+0x236/0x5b0
[] do_sync_write+0x8d/0xd0
[] dump_write+0x52/0x70
[] dump_seek+0xa4/0xe0
[] elf_core_dump+0x896/0x950
[] do_c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77538
--- Comment #9 from Dmitry Vyukov ---
Humm... what are they waiting for? Is it also core dump? Stack for the sleeping
task is missing for some reason.
What kernel version do you use? Maybe the problem is with the kernel? Isn't it
too old?.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78158
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78158
--- Comment #2 from Dmitry Vyukov ---
With -O0 there is huge potential for ODR violations. E.g. code contains:
401774: e8 f3 06 00 00 callq 401e6c
::operator bool() const>
If some other non-instrumented library contains a non-in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77538
--- Comment #12 from Dmitry Vyukov ---
The crash in gdb looks like stack overflow (unsurprising if there are 1MB
frames). Does increasing thread stack size or reducing frame size (there must
something very big on the stack) help?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77538
--- Comment #16 from Dmitry Vyukov ---
> The stack size limit in my box is 8M. I have also checked /proc/limits.
So, is increasing stack size help?
Tsan increases stack consumption. 8MB is not that much provided that you have
1MB frames.
> By e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77538
--- Comment #18 from Dmitry Vyukov ---
Looks like shadow stack overflow.
Do you use fibers, ucontext, longjmp, exceptions or any other non-obvious
control flow constructs?
Fibers and exceptions are not supported. Longjmp should work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78294
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78294
--- Comment #5 from Dmitry Vyukov ---
Markus, how do you configure and build gcc? Is there anything special?
Our tls accesses should not go through __tls_get_addr because we use
initial-exec attribute. __tls_get_addr vs indirect access through g
1 - 100 of 179 matches
Mail list logo
