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
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
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:
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
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
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
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
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
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
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
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
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
[]
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
[]
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
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
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:
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
>
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
25 matches
Mail list logo
