From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id GBjRF00Nz2DhAgAAWB0awg (envelope-from ) for ; Sun, 20 Jun 2021 05:41:33 -0400 Received: by simark.ca (Postfix, from userid 112) id 50DF71F163; Sun, 20 Jun 2021 05:41:33 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED, MAILING_LIST_MULTI,T_DKIM_INVALID,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id B0ED81E813 for ; Sun, 20 Jun 2021 05:41:31 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 28773385E000 for ; Sun, 20 Jun 2021 09:41:31 +0000 (GMT) Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id F3EFB385AC39 for ; Sun, 20 Jun 2021 09:41:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F3EFB385AC39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from imap.suse.de (imap-alt.suse-dmz.suse.de [192.168.254.47]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id EEE6D1FD29; Sun, 20 Jun 2021 09:41:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1624182076; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jhm2+woW6NllTo2Qa67K6zjltSWGmWKVRYeMlTnfUh8=; b=I49Hlq2bYCOTJaP5mHisXk/cardvkbBUekpvq4pHQrM8hyHHI8LGLiyu2wl8q7HZLYsPAt RA2KflpFkaHHMVrYULFJrXfkIam40fV+dEKRGex/MrNif/aO09piI9liniv4ikhKGhokkb NFg2VADmQsb23Dz3UkQlUq7MUyuMV1Y= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1624182076; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jhm2+woW6NllTo2Qa67K6zjltSWGmWKVRYeMlTnfUh8=; b=fdfTv9t7XrUBxC8+CVBXvxClyCqozFw2ddEczvQYaOrS+kpNsXAK9JiJkoEf3P68g07no/ ZGzCzsXRC9qKNGBw== Received: from imap3-int (imap-alt.suse-dmz.suse.de [192.168.254.47]) by imap.suse.de (Postfix) with ESMTP id C6CA8118DD; Sun, 20 Jun 2021 09:41:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1624182076; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jhm2+woW6NllTo2Qa67K6zjltSWGmWKVRYeMlTnfUh8=; b=I49Hlq2bYCOTJaP5mHisXk/cardvkbBUekpvq4pHQrM8hyHHI8LGLiyu2wl8q7HZLYsPAt RA2KflpFkaHHMVrYULFJrXfkIam40fV+dEKRGex/MrNif/aO09piI9liniv4ikhKGhokkb NFg2VADmQsb23Dz3UkQlUq7MUyuMV1Y= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1624182076; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jhm2+woW6NllTo2Qa67K6zjltSWGmWKVRYeMlTnfUh8=; b=fdfTv9t7XrUBxC8+CVBXvxClyCqozFw2ddEczvQYaOrS+kpNsXAK9JiJkoEf3P68g07no/ ZGzCzsXRC9qKNGBw== Received: from director2.suse.de ([192.168.254.72]) by imap3-int with ESMTPSA id eZfxLjwNz2AhfQAALh3uQQ (envelope-from ); Sun, 20 Jun 2021 09:41:16 +0000 Subject: Re: [RFC][gdb/symtab] Lazy expansion of full symbol table From: Tom de Vries To: Tom Tromey References: <20210614093908.GA22709@delia> <87pmwoxj3j.fsf@tromey.com> <533bf7e4-d96c-a6b7-8c37-a4141ebdc761@suse.de> <87im2fxnr7.fsf@tromey.com> <87bl83ykd9.fsf@tromey.com> Message-ID: Date: Sun, 20 Jun 2021 11:41:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 6/19/21 9:36 PM, Tom de Vries wrote: > On 6/18/21 4:30 AM, Tom Tromey wrote: >> Tom> I did an overnight build and test with the updated branch (5bc56d745fd) >> Tom> and ran into some trouble. The first internal-error I investigated >> Tom> happens when parsing the libstdc++ .debug package (so, it was not >> Tom> specific to the test-case). It seems the branch has some trouble with >> Tom> the dwz layout where an abbrev entry is shared between different CUs: >> >> Thank you for trying this, it uncovered several bugs. >> As you can see I haven't gotten to the dwz testing yet... one of the >> issues with DWARF, btw, is that there are just so many modes. >> I.e., I haven't tried DWO or .debug_types yet either. >> > > Yeah, very true. > >> I pushed some patches to fix the crashes but the result is so fast that >> I suspect it is incorrect: >> >> (gdb) file libstdc++.so.6.0.28-10.2.1+git583-lp152.4.1.x86_64.debug >> 2021-06-17 20:25:34.361 - command started >> Reading symbols from libstdc++.so.6.0.28-10.2.1+git583-lp152.4.1.x86_64.debug... >> 2021-06-17 20:25:34.406 - command finished >> Command execution time: 0.075291 (cpu), 0.045521 (wall) >> >> (Though /bin/gdb is also pretty fast here, maybe I'm doing something >> else wrong.) >> >> So, at least it doesn't crash, but more investigation is needed. >> I'll probably add some code to make it easy to dump the index so it's >> easier to see what the scanner recorded. > > Tried the updated branch and ran into a race condition, fixed in > attached patch. Another thing I ran into is a not 100% reproducible segfault. It triggered in gdb.base/advance-until-multiple-locations.exp, when trying to find "test" in the libc debug package. The segfault happens in cooked_index_entry::matches due to the entry parameter being invalid, which is set in this loop: ... for (const cooked_index_entry *entry : per_objfile->per_bfd->cooked_index_table->find (name_vec.back ())) { if (!entry->matches (search_flags) || !entry->matches (domain) || !entry->matches (kind)) continue; ... I could reproduce the segfault with maint set worker-thread 1. Using this debugging code: ... diff --git a/gdb/dwarf2/cooked-index.c b/gdb/dwarf2/cooked-index.c index 7358352fb0b..c75531ac548 100644 --- a/gdb/dwarf2/cooked-index.c +++ b/gdb/dwarf2/cooked-index.c @@ -133,6 +133,43 @@ cooked_index_vector::find (gdb::string_view name) { range result; +#if 1 + auto it = m_entries.begin (); + const char *prev_c = nullptr; + bool prev = true; + for (; it != m_entries.end (); ++it) + { + auto val = *it; + bool res = strncasecmp (val->canonical, name.data (), name.length ()) < 0; + if (res && !prev) + { + fprintf (stderr, "PREV_IT: %s\n", prev_c); + fprintf (stderr, "IT: %s\n", (*it)->canonical); + fprintf (stderr, "PREV_IT: %d\n", + strncasecmp (prev_c, name.data (), name.length ())); + fprintf (stderr, "IT: %d\n", + strncasecmp ((*it)->canonical, name.data (), name.length ())); + gdb_assert_not_reached (""); + } + prev = res; + prev_c = val->canonical; + } +#endif ... I found out that the precondition for using std::lower_bound of the vector being sorted in a certain way is not valid: ... PREV_IT: uint32_t IT: tcbhead_t PREV_IT: 1 IT: -2 ... so my hypothesis is that this causes the segfault somehow. The test passes reliable when sorting at the entry of cooked_index_vector::find (which is of course inefficient). Thanks, - Tom