From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id DDE1138708DB; Mon, 19 Oct 2020 14:52:00 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DDE1138708DB From: "hubicka at ucw dot cz" 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:52:00 +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: hubicka at ucw dot cz 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:52:01 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D97461 --- Comment #9 from Jan Hubicka --- >=20 > They have the very same problem when I disable a statically pre-allocated > buffers with -mllvm -vp-static-alloc=3D0: >=20 > 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/InstrProfil= ingValue.c:101 > #2 0x0000000000401c45 in instrumentTargetValueImpl (CountValue=3D1, > CounterIndex=3D0, Data=3D0x40a2c8, TargetValue=3D4199264) at > /home/marxin/Programming/llvm-project/compiler-rt/lib/profile/InstrProfil= ingValue.c:146 > #3 __llvm_profile_instrument_target (TargetValue=3D4199264, Data=3D0x40a= 2c8, > CounterIndex=3D0) at > /home/marxin/Programming/llvm-project/compiler-rt/lib/profile/InstrProfil= ingValue.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-s= tart.c:270 > #12 0x00000000004012aa in _start () at ../sysdeps/x86_64/start.S:120 Hmm, it seems to me that having some entries prealocated by default would be way to avoid this problem in majority cases w/o having to modify the upstream packages.=20 Honza=