From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id DD0EE3857C63; Mon, 19 Oct 2020 14:15:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DD0EE3857C63 From: "marxin at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug gcov-profile/97461] [11 Regression] allocate_gcov_kvp() deadlocks in firefox LTO+PGO build (overridden malloc() recursion) Date: Mon, 19 Oct 2020 14:15:16 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: gcov-profile X-Bugzilla-Version: 11.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: marxin at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: marxin at gcc dot gnu.org X-Bugzilla-Target-Milestone: 11.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 14:15:17 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D97461 --- Comment #8 from Martin Li=C5=A1ka --- (In reply to Jan Hubicka from comment #7) > > No. The only thing we support is a recursive malloc as seen in: > > ./gcc/testsuite/gcc.dg/tree-prof/indir-call-prof-malloc.c > >=20 > > It was added in g:bc2b1a232b1825b421a1aaa21a0865b2d1e4e08c as we use a > > statically allocated buffer when we recursively entry allocate_gcov_kvp. > >=20 > > However this is different as we can't call malloc/calloc from the funct= ion as > > we're in code that initializes a memory allocator. > >=20 > > We can mitigate the issue with a pair of new functions __gcov_supress_m= alloc > > and __gcov_alloc_malloc that will be called by a custom memory allocato= r. > >=20 > > What do you think about it? >=20 > How this works with the llvm implementation (that is very similar here, > right?) >=20 > Honza They have the very same problem when I disable a statically pre-allocated buffers with -mllvm -vp-static-alloc=3D0: Program received signal SIGILL, Illegal instruction. 0x00000000004014e6 in calloc (nmemb=3D1, size=3D8) at pr97461.c:103 103 if (malloc_depth !=3D 0) __builtin_trap(); (gdb) bt #0 0x00000000004014e6 in calloc (nmemb=3D1, size=3D8) at pr97461.c:103 #1 0x0000000000401ae1 in allocateValueProfileCounters (Data=3D0x40a2c8) at /home/marxin/Programming/llvm-project/compiler-rt/lib/profile/InstrProfilin= gValue.c:101 #2 0x0000000000401c45 in instrumentTargetValueImpl (CountValue=3D1, CounterIndex=3D0, Data=3D0x40a2c8, TargetValue=3D4199264) at /home/marxin/Programming/llvm-project/compiler-rt/lib/profile/InstrProfilin= gValue.c:146 #3 __llvm_profile_instrument_target (TargetValue=3D4199264, Data=3D0x40a2c= 8, CounterIndex=3D0) at /home/marxin/Programming/llvm-project/compiler-rt/lib/profile/InstrProfilin= gValue.c:232 #4 0x000000000040148f in malloc_impl (size=3D56) at pr97461.c:85 #5 0x00000000004013fe in malloc (size=3D56) at pr97461.c:95 #6 0x00007ffff7e048a3 in __add_to_environ (name=3D0x406138 "__LLVM_PROFILE_RT_INIT_ONCE", value=3D, combined=3D, replace=3D) at setenv.c:215 #7 0x0000000000402ce4 in truncateCurrentFile () #8 0x00000000004039bc in parseAndSetFilename () #9 0x0000000000404134 in __llvm_profile_initialize () #10 0x0000000000405e95 in __libc_csu_init (argc=3Dargc@entry=3D1, argv=3Dargv@entry=3D0x7fffffffdfa8, envp=3D0x7fffffffdfb8) at elf-init.c:89 #11 0x00007ffff7decd9a in __libc_start_main (main=3D0x401580
, argc= =3D1, argv=3D0x7fffffffdfa8, init=3D0x405e50 <__libc_csu_init>, fini=3D, rtld_fini=3D, stack_end=3D0x7fffffffdf98) at ../csu/libc-sta= rt.c:270 #12 0x00000000004012aa in _start () at ../sysdeps/x86_64/start.S:120=