https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77538
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77538
--- Comment #24 from peien luo ---
(In reply to Dmitry Vyukov from comment #23)
> 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 call
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77538
--- Comment #22 from peien luo ---
The bt only shows a stack size of 27. No recursion. I modified the tsan code to
print out what's in the shadow stack when it's about to overflow. It looks most
of the addresses are:
__gnu_cxx::__normal_iterator
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 #20 from peien luo ---
(In reply to Dmitry Vyukov from comment #18)
> Looks like shadow stack overflow.
> Do you use fibers, ucontext, longjmp, exceptions or any other non-obvious
> control flow constructs?
> Fibers and exceptions are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77538
--- Comment #19 from peien luo ---
(In reply to Dmitry Vyukov from comment #18)
> Looks like shadow stack overflow.
> Do you use fibers, ucontext, longjmp, exceptions or any other non-obvious
> control flow constructs?
> Fibers and exceptions are
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=77538
--- Comment #17 from peien luo ---
(In reply to Dmitry Vyukov from comment #16)
> > 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 tha
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 #15 from Andrew Pinski ---
0x7f224dab0637 <+23>:sub$0x1000f8,%rsp
0x7fc63563a72d <+29>:sub$0x1000e8,%rsp
We actually use less stack memory with 4.9 so it looks like it was accidently
working on 4.8.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77538
--- Comment #14 from peien luo ---
(In reply to Dmitry Vyukov from comment #12)
> 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 somethin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77538
--- Comment #13 from peien luo ---
(In reply to Dmitry Vyukov from comment #12)
> 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 somethin
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 #11 from peien luo ---
Sorry for the previous comment regarding running in gdb. the result seems to be
random:
Sometimes it can runs fine
Sometimes it gets a SEGFAULT in calling to a function, gdb says:
0x7ff0fa19b466 <+22>:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77538
--- Comment #10 from peien luo ---
It's a centOS7, kernel has been updated to 3.10.0-327.36.3.el7.x86_64, the
problem still occurs. Some new findings:
1, With gcc 4.8.5, it runs fine for this specific case.
2, With gcc 4.9.4, it stucks at some p
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=77538
--- Comment #8 from peien luo ---
In another case, the process got stuck, compiled with gcc 4.9.4. I will try a
different version of gcc. The proc stack info is:
[god@localhost 5019]$ cat task/*/status | grep State
State: D (disk sleep)
State:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77538
--- Comment #7 from peien luo ---
tried, still got D state, build with gcc 4.9.4
[god@localhost 21586]$ cat stack
[] do_exit+0x1e4/0xa60
[] do_group_exit+0x3f/0xa0
[] get_signal_to_deliver+0x1d0/0x6d0
[] do_signal+0x57/0x6c0
[] do_notify_resume+
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 #5 from peien luo ---
(In reply to Dmitry Vyukov from comment #4)
> 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
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 #3 from peien luo ---
The process stuck can be reproduced, the kernel call trace is like:
Sep 16 09:38:37 localhost kernel: test_metaserver D 8803f9307300 0
4250 3896 0x0080
Sep 16 09:38:37 localhost kernel: 880424
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77538
--- Comment #2 from peien luo ---
(In reply to Dmitry Vyukov from comment #1)
> Hello,
>
> Shadow stack size was increased several times, and as far as I remember we
> now have a guard page at the end. Please retest with latest gcc/clang, or
> p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77538
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77538
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment #1
26 matches
Mail list logo
