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 #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 #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 #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
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: coollpe at hotmail 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
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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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
15 matches
Mail list logo
