* [Bug sanitizer/94910] detect_stack_use_after_return=1 is much slower than clang's
2020-05-01 20:51 [Bug sanitizer/94910] New: detect_stack_use_after_return=1 is much slower than clang's rafael at espindo dot la
@ 2020-05-04 5:27 ` marxin at gcc dot gnu.org
2020-05-15 11:31 ` marxin at gcc dot gnu.org
` (14 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-05-04 5:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94910
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2020-05-04
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org
--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Thanks for the report, I'll take a look.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug sanitizer/94910] detect_stack_use_after_return=1 is much slower than clang's
2020-05-01 20:51 [Bug sanitizer/94910] New: detect_stack_use_after_return=1 is much slower than clang's rafael at espindo dot la
2020-05-04 5:27 ` [Bug sanitizer/94910] " marxin at gcc dot gnu.org
@ 2020-05-15 11:31 ` marxin at gcc dot gnu.org
2020-05-15 16:28 ` rafael at espindo dot la
` (13 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-05-15 11:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94910
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |WAITING
--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
I'm sorry but I can't install all pre-requisites.
Do you have a Docker/podman I can use to build the package?
Or do you have a reduced test-case?
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug sanitizer/94910] detect_stack_use_after_return=1 is much slower than clang's
2020-05-01 20:51 [Bug sanitizer/94910] New: detect_stack_use_after_return=1 is much slower than clang's rafael at espindo dot la
2020-05-04 5:27 ` [Bug sanitizer/94910] " marxin at gcc dot gnu.org
2020-05-15 11:31 ` marxin at gcc dot gnu.org
@ 2020-05-15 16:28 ` rafael at espindo dot la
2020-05-18 9:11 ` marxin at gcc dot gnu.org
` (12 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: rafael at espindo dot la @ 2020-05-15 16:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94910
--- Comment #3 from Rafael Avila de Espindola <rafael at espindo dot la> ---
Yes, our build bots use podman, so you can reproduce with:
$ git clone https://github.com/scylladb/seastar
$ cd seastar
$ podman run -v $PWD:$PWD:z -w $PWD -it
docker.io/scylladb/scylla-toolchain:fedora-31-20200512
$ mkdir build
$ cd build
$ cmake -DCMAKE_BUILD_TYPE=Debug -G Ninja ../
$ ninja tests/unit/chunked_fifo_test
$ time ASAN_OPTIONS=detect_stack_use_after_return=0
./tests/unit/chunked_fifo_test -t chunked_fifo_big
$ time ASAN_OPTIONS=detect_stack_use_after_return=1
./tests/unit/chunked_fifo_test -t chunked_fifo_big
$ cd ..
$ dnf install clang
$ mkdir build-clang
$ cd build-clang
$ CC=clang CXX=clang++ cmake -DCMAKE_BUILD_TYPE=Debug -G Ninja ../
-DSeastar_CXX_FLAGS=-Wno-error
$ ninja tests/unit/chunked_fifo_test
$ time ASAN_OPTIONS=detect_stack_use_after_return=0
./tests/unit/chunked_fifo_test -t chunked_fifo_big
$ time ASAN_OPTIONS=detect_stack_use_after_return=1
./tests/unit/chunked_fifo_test -t chunked_fifo_big
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug sanitizer/94910] detect_stack_use_after_return=1 is much slower than clang's
2020-05-01 20:51 [Bug sanitizer/94910] New: detect_stack_use_after_return=1 is much slower than clang's rafael at espindo dot la
` (2 preceding siblings ...)
2020-05-15 16:28 ` rafael at espindo dot la
@ 2020-05-18 9:11 ` marxin at gcc dot gnu.org
2020-05-18 9:12 ` marxin at gcc dot gnu.org
` (11 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-05-18 9:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94910
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |NEW
--- Comment #4 from Martin Liška <marxin at gcc dot gnu.org> ---
I was able to reproduce that!
The problem is the number of fake stacks that are exhausted.
I see 27000x:
FakeStack (stack_size_log=20):succ after 0
FakeStack (stack_size_log=20):succ after 0
FakeStack (stack_size_log=20):succ after 0
FakeStack (stack_size_log=20):succ after 0
...
FakeStack (stack_size_log=20):bail out after 8192
FakeStack (stack_size_log=20):bail out after 16384
FakeStack (stack_size_log=20):bail out after 4096
FakeStack (stack_size_log=20):bail out after 8192
...
So it seems that the program uses enormous number of stacks. Or the run-time
does not release them in an efficient way.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug sanitizer/94910] detect_stack_use_after_return=1 is much slower than clang's
2020-05-01 20:51 [Bug sanitizer/94910] New: detect_stack_use_after_return=1 is much slower than clang's rafael at espindo dot la
` (3 preceding siblings ...)
2020-05-18 9:11 ` marxin at gcc dot gnu.org
@ 2020-05-18 9:12 ` marxin at gcc dot gnu.org
2020-05-18 10:39 ` jakub at gcc dot gnu.org
` (10 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-05-18 9:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94910
--- Comment #5 from Martin Liška <marxin at gcc dot gnu.org> ---
> FakeStack (stack_size_log=20):bail out after 8192
> FakeStack (stack_size_log=20):bail out after 16384
> FakeStack (stack_size_log=20):bail out after 4096
> FakeStack (stack_size_log=20):bail out after 8192
> ...
This comes after the 27000 success Fake stack allocations.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug sanitizer/94910] detect_stack_use_after_return=1 is much slower than clang's
2020-05-01 20:51 [Bug sanitizer/94910] New: detect_stack_use_after_return=1 is much slower than clang's rafael at espindo dot la
` (4 preceding siblings ...)
2020-05-18 9:12 ` marxin at gcc dot gnu.org
@ 2020-05-18 10:39 ` jakub at gcc dot gnu.org
2020-05-19 13:26 ` marxin at gcc dot gnu.org
` (9 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-05-18 10:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94910
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #5)
> > FakeStack (stack_size_log=20):bail out after 8192
> > FakeStack (stack_size_log=20):bail out after 16384
> > FakeStack (stack_size_log=20):bail out after 4096
> > FakeStack (stack_size_log=20):bail out after 8192
> > ...
>
> This comes after the 27000 success Fake stack allocations.
I guess the important question is what is different with clang that it behaves
differently, whether it allocates fake stack for fewer functions, or what else.
E.g. try ltrace on it to see how many each one allocates and if it is very
different, it would be nice to understand why.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug sanitizer/94910] detect_stack_use_after_return=1 is much slower than clang's
2020-05-01 20:51 [Bug sanitizer/94910] New: detect_stack_use_after_return=1 is much slower than clang's rafael at espindo dot la
` (5 preceding siblings ...)
2020-05-18 10:39 ` jakub at gcc dot gnu.org
@ 2020-05-19 13:26 ` marxin at gcc dot gnu.org
2020-05-19 21:05 ` rafael at espindo dot la
` (8 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-05-19 13:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94910
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org
--- Comment #7 from Martin Liška <marxin at gcc dot gnu.org> ---
I was able to reproduce that on tramp3d as well. I bet the problem is that the
inline expansion does not clear:
**SavedFlagPtr(FakeStack) = 0
as LLVM does:
https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp#L3279-L3292
Let me take a look.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug sanitizer/94910] detect_stack_use_after_return=1 is much slower than clang's
2020-05-01 20:51 [Bug sanitizer/94910] New: detect_stack_use_after_return=1 is much slower than clang's rafael at espindo dot la
` (6 preceding siblings ...)
2020-05-19 13:26 ` marxin at gcc dot gnu.org
@ 2020-05-19 21:05 ` rafael at espindo dot la
2020-05-20 9:11 ` marxin at gcc dot gnu.org
` (7 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: rafael at espindo dot la @ 2020-05-19 21:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94910
--- Comment #8 from Rafael Avila de Espindola <rafael at espindo dot la> ---
I can confirm that the proposed patch fixes the issue for me.
Thank you so much!
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug sanitizer/94910] detect_stack_use_after_return=1 is much slower than clang's
2020-05-01 20:51 [Bug sanitizer/94910] New: detect_stack_use_after_return=1 is much slower than clang's rafael at espindo dot la
` (7 preceding siblings ...)
2020-05-19 21:05 ` rafael at espindo dot la
@ 2020-05-20 9:11 ` marxin at gcc dot gnu.org
2020-05-25 8:32 ` marxin at gcc dot gnu.org
` (6 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-05-20 9:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94910
--- Comment #9 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Rafael Avila de Espindola from comment #8)
> I can confirm that the proposed patch fixes the issue for me.
>
> Thank you so much!
I thank you for the bug report. We had the regression since the very beginning!
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug sanitizer/94910] detect_stack_use_after_return=1 is much slower than clang's
2020-05-01 20:51 [Bug sanitizer/94910] New: detect_stack_use_after_return=1 is much slower than clang's rafael at espindo dot la
` (8 preceding siblings ...)
2020-05-20 9:11 ` marxin at gcc dot gnu.org
@ 2020-05-25 8:32 ` marxin at gcc dot gnu.org
2020-06-10 11:19 ` cvs-commit at gcc dot gnu.org
` (5 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-05-25 8:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94910
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |frantisek at sumsal dot cz
--- Comment #10 from Martin Liška <marxin at gcc dot gnu.org> ---
*** Bug 95275 has been marked as a duplicate of this bug. ***
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug sanitizer/94910] detect_stack_use_after_return=1 is much slower than clang's
2020-05-01 20:51 [Bug sanitizer/94910] New: detect_stack_use_after_return=1 is much slower than clang's rafael at espindo dot la
` (9 preceding siblings ...)
2020-05-25 8:32 ` marxin at gcc dot gnu.org
@ 2020-06-10 11:19 ` cvs-commit at gcc dot gnu.org
2020-06-10 11:20 ` marxin at gcc dot gnu.org
` (4 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-06-10 11:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94910
--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Martin Liska <marxin@gcc.gnu.org>:
https://gcc.gnu.org/g:8b6731e674c76cb48a417f2eef74ced92a17f469
commit r11-1145-g8b6731e674c76cb48a417f2eef74ced92a17f469
Author: Martin Liska <mliska@suse.cz>
Date: Tue May 19 16:57:56 2020 +0200
Add missing store in emission of asan_stack_free.
gcc/ChangeLog:
2020-05-19 Martin Liska <mliska@suse.cz>
PR sanitizer/94910
* asan.c (asan_emit_stack_protection): Emit
also **SavedFlagPtr(FakeStack, class_id) = 0 in order to release
a stack frame.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug sanitizer/94910] detect_stack_use_after_return=1 is much slower than clang's
2020-05-01 20:51 [Bug sanitizer/94910] New: detect_stack_use_after_return=1 is much slower than clang's rafael at espindo dot la
` (10 preceding siblings ...)
2020-06-10 11:19 ` cvs-commit at gcc dot gnu.org
@ 2020-06-10 11:20 ` marxin at gcc dot gnu.org
2020-06-12 8:03 ` cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-06-10 11:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94910
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Known to work| |11.0
Known to fail| |10.1.0, 8.4.0, 9.3.0
--- Comment #12 from Martin Liška <marxin at gcc dot gnu.org> ---
Fixed on master so far.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug sanitizer/94910] detect_stack_use_after_return=1 is much slower than clang's
2020-05-01 20:51 [Bug sanitizer/94910] New: detect_stack_use_after_return=1 is much slower than clang's rafael at espindo dot la
` (11 preceding siblings ...)
2020-06-10 11:20 ` marxin at gcc dot gnu.org
@ 2020-06-12 8:03 ` cvs-commit at gcc dot gnu.org
2020-06-12 8:17 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-06-12 8:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94910
--- Comment #13 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Martin Liska
<marxin@gcc.gnu.org>:
https://gcc.gnu.org/g:036b288ca4cf5d3b1d908ef97c25b7f92153ff8a
commit r10-8283-g036b288ca4cf5d3b1d908ef97c25b7f92153ff8a
Author: Martin Liska <mliska@suse.cz>
Date: Tue May 19 16:57:56 2020 +0200
Add missing store in emission of asan_stack_free.
gcc/ChangeLog:
2020-05-19 Martin Liska <mliska@suse.cz>
PR sanitizer/94910
* asan.c (asan_emit_stack_protection): Emit
also **SavedFlagPtr(FakeStack, class_id) = 0 in order to release
a stack frame.
(cherry picked from commit 8b6731e674c76cb48a417f2eef74ced92a17f469)
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug sanitizer/94910] detect_stack_use_after_return=1 is much slower than clang's
2020-05-01 20:51 [Bug sanitizer/94910] New: detect_stack_use_after_return=1 is much slower than clang's rafael at espindo dot la
` (12 preceding siblings ...)
2020-06-12 8:03 ` cvs-commit at gcc dot gnu.org
@ 2020-06-12 8:17 ` cvs-commit at gcc dot gnu.org
2020-06-12 8:30 ` cvs-commit at gcc dot gnu.org
2020-06-12 8:30 ` marxin at gcc dot gnu.org
15 siblings, 0 replies; 17+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-06-12 8:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94910
--- Comment #14 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Martin Liska
<marxin@gcc.gnu.org>:
https://gcc.gnu.org/g:877d8d63228579bd56f94e6c56fbfeb015da08e5
commit r9-8671-g877d8d63228579bd56f94e6c56fbfeb015da08e5
Author: Martin Liska <mliska@suse.cz>
Date: Tue May 19 16:57:56 2020 +0200
Add missing store in emission of asan_stack_free.
gcc/ChangeLog:
2020-05-19 Martin Liska <mliska@suse.cz>
PR sanitizer/94910
* asan.c (asan_emit_stack_protection): Emit
also **SavedFlagPtr(FakeStack, class_id) = 0 in order to release
a stack frame.
(cherry picked from commit 8b6731e674c76cb48a417f2eef74ced92a17f469)
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug sanitizer/94910] detect_stack_use_after_return=1 is much slower than clang's
2020-05-01 20:51 [Bug sanitizer/94910] New: detect_stack_use_after_return=1 is much slower than clang's rafael at espindo dot la
` (13 preceding siblings ...)
2020-06-12 8:17 ` cvs-commit at gcc dot gnu.org
@ 2020-06-12 8:30 ` cvs-commit at gcc dot gnu.org
2020-06-12 8:30 ` marxin at gcc dot gnu.org
15 siblings, 0 replies; 17+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-06-12 8:30 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94910
--- Comment #15 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-8 branch has been updated by Martin Liska
<marxin@gcc.gnu.org>:
https://gcc.gnu.org/g:5d746191e271949e530d9e5f46cde7e7bf08272f
commit r8-10307-g5d746191e271949e530d9e5f46cde7e7bf08272f
Author: Martin Liska <mliska@suse.cz>
Date: Tue May 19 16:57:56 2020 +0200
Add missing store in emission of asan_stack_free.
gcc/ChangeLog:
2020-05-19 Martin Liska <mliska@suse.cz>
PR sanitizer/94910
* asan.c (asan_emit_stack_protection): Emit
also **SavedFlagPtr(FakeStack, class_id) = 0 in order to release
a stack frame.
(cherry picked from commit 8b6731e674c76cb48a417f2eef74ced92a17f469)
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug sanitizer/94910] detect_stack_use_after_return=1 is much slower than clang's
2020-05-01 20:51 [Bug sanitizer/94910] New: detect_stack_use_after_return=1 is much slower than clang's rafael at espindo dot la
` (14 preceding siblings ...)
2020-06-12 8:30 ` cvs-commit at gcc dot gnu.org
@ 2020-06-12 8:30 ` marxin at gcc dot gnu.org
15 siblings, 0 replies; 17+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-06-12 8:30 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94910
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #16 from Martin Liška <marxin at gcc dot gnu.org> ---
Fixed on all active branches.
^ permalink raw reply [flat|nested] 17+ messages in thread