Hi Jason, I managed to reproduce this fault now.
and entered a bug tracker for it: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64265 any ideas how this patch could move the __tsan_func_entry into the loop? Thanks Bernd. On Wed, 10 Dec 2014 00:10:07, Bernd Edlinger wrote: > > Hi Jason, > >> I ran the tramp3d benchmark over 500 iterations before and after the > change and couldn't see any measurable difference in runtime. The > binary with my >> change was 0.4% smaller. > I'm going to go ahead and check it in; if a performance hit shows up on > the automated testing we can revisit the choice. > > Unfortunately, this checkin broke the thread sanitizer: > > r217669 | jason | 2014-11-17 20:08:02 +0100 (Mo, 17. Nov 2014) | 2 Zeilen > > * cp-gimplify.c (genericize_cp_loop): Use LOOP_EXPR. > (genericize_for_stmt): Handle null statement-list. > > > therefore I would kindly ask you to revert this again. > > After that patch some C++ functions moved the call to the __tsan_func_entry > into the loop. > And we get crashes or major memory leaks from this, if the software is > compiled with -fsanitize=thread. > > This happens in a software package on which I currently work. It is called > Softing OPC UA Toolbox. > > I found this in the generated assembler code by bisection: > > 000000000092747d > <_ZNSt12_Destroy_auxILb0EE9__destroyIPN18SoftingOPCToolbox55ValueEEEvT_S5_>: > 92747d: 55 push %rbp > 92747e: 48 89 e5 mov %rsp,%rbp > 927481: 53 push %rbx > 927482: 48 83 ec 18 sub $0x18,%rsp > 927486: 48 89 7d e8 mov %rdi,-0x18(%rbp) > 92748a: 48 89 75 e0 mov %rsi,-0x20(%rbp) > 92748e: 48 8b 45 08 mov 0x8(%rbp),%rax > 927492: 48 89 c7 mov %rax,%rdi > 927495: e8 26 33 fe ff callq 90a7c0 <__tsan_func_entry@plt> > 92749a: 48 8b 45 e8 mov -0x18(%rbp),%rax > 92749e: 48 3b 45 e0 cmp -0x20(%rbp),%rax > 9274a2: 74 3d je 9274e1 > <_ZNSt12_Destroy_auxILb0EE9__destroyIPN18SoftingOPCToolbox55ValueEEEvT_S5_+0x64> > 9274a4: 48 8b 5d e8 mov -0x18(%rbp),%rbx > 9274a8: 48 89 d8 mov %rbx,%rax > 9274ab: 48 85 db test %rbx,%rbx > 9274ae: 74 0b je 9274bb > <_ZNSt12_Destroy_auxILb0EE9__destroyIPN18SoftingOPCToolbox55ValueEEEvT_S5_+0x3e> > 9274b0: 48 89 c2 mov %rax,%rdx > 9274b3: 83 e2 07 and $0x7,%edx > 9274b6: 48 85 d2 test %rdx,%rdx > 9274b9: 74 0f je 9274ca > <_ZNSt12_Destroy_auxILb0EE9__destroyIPN18SoftingOPCToolbox55ValueEEEvT_S5_+0x4d> > 9274bb: 48 89 c6 mov %rax,%rsi > 9274be: 48 8d 3d 1b a3 f8 00 lea 0xf8a31b(%rip),%rdi # > 18b17e0 <DW.ref.__gxx_personality_v0+0x11878> > 9274c5: e8 06 36 fe ff callq 90aad0 > <__ubsan_handle_type_mismatch@plt> > 9274ca: 48 89 df mov %rbx,%rdi > 9274cd: e8 1b 09 00 00 callq 927ded > <_ZSt11__addressofIN18SoftingOPCToolbox55ValueEEPT_RS2_> > 9274d2: 48 89 c7 mov %rax,%rdi > 9274d5: e8 21 09 00 00 callq 927dfb > <_ZSt8_DestroyIN18SoftingOPCToolbox55ValueEEvPT_> > 9274da: 48 83 45 e8 20 addq $0x20,-0x18(%rbp) > 9274df: eb ad jmp 92748e > <_ZNSt12_Destroy_auxILb0EE9__destroyIPN18SoftingOPCToolbox55ValueEEEvT_S5_+0x11> > 9274e1: e8 da 2c fe ff callq 90a1c0 <__tsan_func_exit@plt> > 9274e6: 48 83 c4 18 add $0x18,%rsp > 9274ea: 5b pop %rbx > 9274eb: 5d pop %rbp > 9274ec: c3 retq > 9274ed: 90 nop > > > see the jmp at 9274df: it jumps to _before_ the tsan_func_entry. > I am not sure how to locate the source code of the above assembler section. > But I'd guess, it must be some kind of automatically generated default > destructor. > > All I can say in the moment, that it is was working perfectly before Nov 17. > > > Thanks > Bernd. >
