From patchwork Sun May 14 16:09:35 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?S=C3=B6ren_Tempel?= X-Patchwork-Id: 93733 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp6388331vqo; Sun, 14 May 2023 09:10:29 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7C7rMnTlRuOxUrunly4iXIC0bsf8Avv59Q4wjyahclo6dN84HJSEyIX8mLRWaetrskg40d X-Received: by 2002:aa7:cfcb:0:b0:506:83e7:8c6c with SMTP id r11-20020aa7cfcb000000b0050683e78c6cmr25307269edy.10.1684080629074; Sun, 14 May 2023 09:10:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684080629; cv=none; d=google.com; s=arc-20160816; b=L7o8MdKtLXcBbYWX4YeaGhQkpprkbX0o8R1KsStnLmKBPqGFPIWcvbcChtKKMeD3XX /+sdo/Hbh3VAjyrV7PiGCrpMsx4uBOVk0cIXdij8ko3H56ssSL7i+Pr+WXCvUMHafg2Z tOQcd9x3U5yOMyVpGKGWB4xAyjc4wtjBdGt//FZaZBUOBiO2orMLEmnq9JWwm5li3qm1 +VvPT2Ic/VUnWFVbGEXqIsZMsiMmPWlXK/Bj7g7FVajubCKLnmp1+u1RhHXXat9rnZ3Y BjNistJXt53sNGljy0yRwModKzLc5fLxN8bqQYfyPedv3hWNjx/dXQ/6Thefpn+u6Eh3 2m9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:reply-to:from:list-subscribe:list-help:list-post :list-archive:list-unsubscribe:list-id:precedence:mime-version :message-id:subject:cc:to:date:dmarc-filter:delivered-to :dkim-signature:dkim-filter; bh=8SXviZf6zrPJU6aJeMeU/NVG2uB3YCrE6auSxJ8VCvE=; b=SjI8fo2PoXO2ztymK5MdF2ESGUiu8AGIX8mEczc13E+i/jqLn2i+avoSlTNpvm2hbC hRyBGpEmmiXZeRGcOFFff9Aa35bwfnmn5LRVQGmoOHRbIcHyEPmMGHEOzpdfZiiSQFl7 HJgbU1KZYRL+Xrb8hgWE339H/2qs+DmtLdImljYfwe+b3GWq4CYnpi6xQ0emfmvZElwt JAlH/X0n8y+u42c1XKluaPRTje3YSxMG/v+DOz6RCXEfkejYeliC2uJid+5CPbb0Zzg3 6ILrRldcWedSEKpwiBiAxIx+glLrN3H897AvQgCDi3gb3HCvhMDkUkOOwW1f6jWTxT0O Y4rg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=c422Y6yJ; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from sourceware.org (server2.sourceware.org. [2620:52:3:1:0:246e:9693:128c]) by mx.google.com with ESMTPS id j5-20020aa7ca45000000b00509d6adb64csi9889316edt.29.2023.05.14.09.10.28 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 14 May 2023 09:10:29 -0700 (PDT) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) client-ip=2620:52:3:1:0:246e:9693:128c; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=c422Y6yJ; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 53F9E3858433 for ; Sun, 14 May 2023 16:10:27 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 53F9E3858433 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1684080627; bh=8SXviZf6zrPJU6aJeMeU/NVG2uB3YCrE6auSxJ8VCvE=; h=Date:To:Cc:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=c422Y6yJavLmeR8ZN6gzM+WggcNIhK+vp5CpUb2wKh8GhB5PgfYZvxr1JpFHbjmV+ 3nRGz04uvh2ga2FkJwa56+Z392e5IIjR/FOKEHlkkLkAsE5HIQcQNqqXBqI1Ooi6k3 woMDf6YfLQefUcf7+GSuD9I3ysGDyAxb0TqEIB3c= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from magnesium.8pit.net (magnesium.8pit.net [45.76.88.171]) by sourceware.org (Postfix) with ESMTPS id ECB48385840E for ; Sun, 14 May 2023 16:09:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org ECB48385840E Received: from localhost ( [2a02:8109:3b40:398a:3ea7:a648:38d:8056]) by magnesium.8pit.net (OpenSMTPD) with ESMTPSA id d9889997 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:YES); Sun, 14 May 2023 18:09:39 +0200 (CEST) Date: Sun, 14 May 2023 18:09:35 +0200 To: neumann@in.tum.de Cc: gcc-patches@gcc.gnu.org, tneumann@users.sourceforge.net, alice@ayaya.dev Subject: [PATCH] Fix assertion for unwind-dw2-fde.c btree changes Message-Id: <2TMB4YQOP1E1R.2QLW7HCD1NVF3@8pit.net> MIME-Version: 1.0 X-Spam-Status: No, score=-13.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_LOTSOFHASH, KAM_SHORT, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: =?utf-8?q?S=C3=B6ren_Tempel_via_Gcc-patches?= From: =?utf-8?q?S=C3=B6ren_Tempel?= Reply-To: =?utf-8?b?U8O2cmVu?= Tempel Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org Sender: "Gcc-patches" X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1765886529699576462?= X-GMAIL-MSGID: =?utf-8?q?1765886529699576462?= Dear Thomas Neumann, I am contacting you as the author of the commit with commit hash 6e80a1d164d1f996ad08a512c000025a7c2ca893 [1] in the GCC repository. In this commit, you refactored the __register_frame/__deregister_frame implementation in GCC. The commit is part of the GCC 13 release. While upgrading the GCC version in Alpine Linux from GCC 12 to GCC 13 we ran into a regression introduced by these changes. The regression manifests itself in a failing assertion in __deregister_frame_info_bases. The assertion failure was observed while using Chromium's `flatc` build system tool. The failing assertion is: unwind-dw2-fde.c:281 gcc_assert (in_shutdown || ob); The assertion fails for us because ob is a null pointer and in_shutdown is zero. The backtrace for the assertion failure looks as follows: #0 __restore_sigs (set=set@entry=0x7fffffffe050) at ./arch/x86_64/syscall_arch.h:40 #1 0x00007ffff7facea5 in raise (sig=sig@entry=6) at src/signal/raise.c:11 #2 0x00007ffff7f7ffa8 in abort () at src/exit/abort.c:11 #3 0x00007ffff7f3d411 in __deregister_frame_info_bases (begin=0x55555557ef58) at /home/buildozer/aports/main/gcc/src/gcc-13-20230506/libgcc/unwind-dw2-fde.c:281 #4 __deregister_frame_info_bases (begin=0x55555557ef58) at /home/buildozer/aports/main/gcc/src/gcc-13-20230506/libgcc/unwind-dw2-fde.c:219 #5 0x0000555555580072 in __do_global_dtors_aux () #6 0x000000185eb03fee in ?? () #7 0x00007ffff7fc1ad6 in __libc_exit_fini () at ldso/dynlink.c:1453 #8 0x00007ffff7f78082 in exit (code=1) at src/exit/exit.c:30 #9 0x00005555555802a6 in Error(flatbuffers::FlatCompiler const*, std::__cxx11::basic_string, std::allocator > const&, bool, bool) () #10 0x000055555560f952 in flatbuffers::FlatCompiler::ParseFromCommandLineArguments(int, char const**) () #11 0x0000555555581b42 in main ( I noticed that you already pushed a fixup for the aforementioned assertion in commit 386ebf75f4c0342b1f823f4e4aba07abda3288d1 [2]. However, I believe there is one more edge case that isn't being account for presently: If the inserted entry has a size of 0 (i.e. if range[1] - range[0] == 0) then the btree_insert call in __register_frame_info_bases will not insert anything. This is not accounted for in __deregister_frame_info_bases as it is assumed that the prior btree_insert call in __register_frame_info_bases always inserted something into the lookup data structure. Based on the information contained in the backtrace shown above, this behavior can be observed in the following gdb debug session: (gdb) break __register_frame_info_bases if begin==0x55555557ef58 (gdb) run Breakpoint 11.1, __register_frame_info_bases (begin=0x55555557ef58, ob=0x555555907f60 , tbase=0x0, dbase=0x0) at /home/buildozer/aports/main/gcc/src/gcc-13-20230506/libgcc/unwind-dw2-fde.c:111 (gdb) break btree_insert (gdb) cont Continuing. Breakpoint 12, btree_insert (base=0, size=0, ob=0x555555907f60 , t=0x7ffff7f5d290 ) at /home/buildozer/aports/main/gcc/src/gcc-13-20230506/libgcc/unwind-dw2-btree.h:726 726 if (!size) (gdb) p size $1 = 0 (gdb) next 727 return false; From the above debug output, we can deduce that nothing was inserted into the lookup data structure for the frame beginning at 0x55555557ef58 because the size of the range is zero. If we set at breakpoint in __deregister_frame_info_bases for the same frame we can observe the following: (gdb) break __deregister_frame_info_bases if begin==0x55555557ef58 Continuing. /home/buildozer/aports/community/chromium/src/chromium-113.0.5672.92/out/bld/flatc: Breakpoint 13.1, __deregister_frame_info_bases (begin=0x55555557ef58) at /home/buildozer/aports/main/gcc/src/gcc-13-20230506/libgcc/unwind-dw2-fde.c:220 (gdb) break unwind-dw2-fde.c:242 (gdb) cont 242 ob = btree_remove (®istered_frames, range[0]); (gdb) p range $2 = {0, 0} (gdb) next (gdb) p ob $3 = 0x0 Naturally, since nothing was inserted into the lookup data structure for this frame, btree_remove isn't able to remove anything and returns a null pointer for ob. This then causes the aforementioned assertion failure. A git-format-patch(1) for the assertion is attached, which adds handling for the edge case that nothing was inserted via btree_insert in __register_frame_info_bases to __deregister_frame_info_bases. Would be cool if this could be fixed on the GCC trunk. Greetings Sören Tempel [1]: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=6e80a1d164d1f996ad08a512c000025a7c2ca893 [2]: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=386ebf75f4c0342b1f823f4e4aba07abda3288d1 From 6dc56564cad69a26595cc38956355e5be7d2c2b0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=B6ren=20Tempel?= Date: Sun, 14 May 2023 19:30:21 +0200 Subject: [PATCH] fix assert in __deregister_frame_info_bases MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The assertion in __deregister_frame_info_bases assumes that for every frame something was inserted into the lookup data structure by __register_frame_info_bases. Unfortunately, this does not necessarily hold true as the btree_insert call in __register_frame_info_bases will not insert anything for empty ranges. Therefore, we need to explicitly account for such empty ranges in the assertion as `ob` will be a null pointer for such ranges, hence causing the assertion to fail. Signed-off-by: Sören Tempel --- libgcc/unwind-dw2-fde.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/libgcc/unwind-dw2-fde.c b/libgcc/unwind-dw2-fde.c index 7b74c391ced..8683a65aa02 100644 --- a/libgcc/unwind-dw2-fde.c +++ b/libgcc/unwind-dw2-fde.c @@ -278,7 +278,9 @@ __deregister_frame_info_bases (const void *begin) __gthread_mutex_unlock (&object_mutex); #endif - gcc_assert (in_shutdown || ob); + // If we didn't find anything in the lookup data structures then they + // were either already destroyed or we tried to remove an empty range. + gcc_assert (in_shutdown || ((range[1] - range[0]) == 0 || ob)); return (void *) ob; }