From patchwork Tue Dec 17 23:42:03 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Terekhov, Mikhail via Gdb-patches" X-Patchwork-Id: 36935 Received: (qmail 121783 invoked by alias); 17 Dec 2019 23:42:10 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 121756 invoked by uid 89); 17 Dec 2019 23:42:10 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-25.1 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.1 spammy=presented, our X-HELO: mail-pl1-f201.google.com Received: from mail-pl1-f201.google.com (HELO mail-pl1-f201.google.com) (209.85.214.201) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 17 Dec 2019 23:42:09 +0000 Received: by mail-pl1-f201.google.com with SMTP id p11so12003plo.6 for ; Tue, 17 Dec 2019 15:42:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:message-id:mime-version:subject:from:to:cc; bh=q1WpXnT/GbHkmAW3MPBC63B2lweG9CtjsUVzGEHE6g0=; b=iIVdNuwJBOaJHO+Uz+HwOe+mF6uoVgsGOdaAco1INzk7+8YmLr/CU3/wTwYXa423rJ rOqf8GelZ/uVY4nTGrh2xxSKzBPYVwO9IpSujM/96/03B9tZqwTrD0JjZTYb/SWH+pyv d2eukxIHhvNLGlCHYpEIyO87kgP2x96ID7jPbz9CI1l+GsBlSkY3hrzZud7a+12S95xr +VeCcRAczVmVIKT+epgTxqeHnz9163ADiWC5WKeOqO5nUA9fnSHEK3D4Zr72u0NhMCzW PH0Cf5Kr4B0emhCSDjDb3UedhBCDG2rulOnTafBRK0sJn+falWgDH7SkNp5D984LIYEF SRlw== Date: Tue, 17 Dec 2019 15:42:03 -0800 Message-Id: <20191217234203.22520-1-tamur@google.com> Mime-Version: 1.0 Subject: [PATCH] Remove gdb_assert in dw2_find_pc_sect_compunit_symtab. X-Patchwork-Original-From: "Ali Tamur via gdb-patches" From: "Terekhov, Mikhail via Gdb-patches" Reply-To: Ali Tamur To: gdb-patches@sourceware.org Cc: Ali Tamur X-IsSubscribed: yes All callers (such as find_pc_sect_compunit_symtab in symtab.c) check the return value and take meaningful action if it is null. The problem with the gdb_assert is that, although the function should never return null with well formed debug info, it does when for example .gdb_index section of the object file is faulty. I am debugging a rare and not easy to reproduce crash in our code base, and this assertion prevents the user seeing the full stack trace. When this assertion is removed, gdb falls back to not using gdb_index information and prints a useful stack trace. Apart from the separate issue of finding out why gdb_index is corrupted, I am guessing that gdb should be resilient when presented with bad debug info. gdb/ChangeLog * dwarf2read.c (dw2_find_pc_sect_compunit_symtab): Remove gdb_assert. --- gdb/dwarf2read.c | 1 - 1 file changed, 1 deletion(-) diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c index 9178e0eb94..5f1a58c728 100644 --- a/gdb/dwarf2read.c +++ b/gdb/dwarf2read.c @@ -5258,7 +5258,6 @@ dw2_find_pc_sect_compunit_symtab (struct objfile *objfile, = recursively_find_pc_sect_compunit_symtab (dw2_instantiate_symtab (data, false), pc); - gdb_assert (result != NULL); return result; }