From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id 17105385828E for ; Tue, 5 Jul 2022 08:17:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 17105385828E Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 0E03F1FA88; Tue, 5 Jul 2022 08:17:06 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id EBCDD13A79; Tue, 5 Jul 2022 08:17:05 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id SllfOIHzw2JCTQAAMHmgww (envelope-from ); Tue, 05 Jul 2022 08:17:05 +0000 Message-ID: <7d4271d4-5b01-3ddf-fc39-8a4f7e40d9ab@suse.de> Date: Tue, 5 Jul 2022 10:17:05 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [PATCH 5/5] [gdb/symtab] Fix data race on per_cu->lang Content-Language: en-US To: Tom Tromey Cc: gdb-patches@sourceware.org References: <20220629152914.13149-1-tdevries@suse.de> <20220629152914.13149-5-tdevries@suse.de> <877d4svih2.fsf@tromey.com> From: Tom de Vries In-Reply-To: <877d4svih2.fsf@tromey.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-12.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, NICE_REPLY_A, 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: 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: , X-List-Received-Date: Tue, 05 Jul 2022 08:17:08 -0000 On 7/4/22 20:30, Tom Tromey wrote: >>>>>> "Tom" == Tom de Vries writes: > > Tom> Both writes are called from the parallel for in dwarf2_build_psymtabs_hard, > Tom> this one directly: > Tom> ... > Tom> #1 process_psymtab_comp_unit gdb/dwarf2/read.c:6812 (gdb+0x830912) > Tom> #2 operator() gdb/dwarf2/read.c:7102 (gdb+0x831902) > Tom> #3 operator() gdb/../gdbsupport/parallel-for.h:171 (gdb+0x8723a8) > Tom> ... > Tom> and this one when handling cross-CU refs: > Tom> ... > Tom> #1 cooked_indexer::ensure_cu_exists(cutu_reader*, dwarf2_per_objfile*, \ > Tom> sect_offset, bool, bool) gdb/dwarf2/read.c:17973 (gdb+0x85c522) > > This method tries to ensure that a CU isn't processed twice, using the > 'scanned' field. Do you know why this isn't working? > Yes, because for_scanning == false, so this: ... /* When scanning, we only want to visit a given CU a single time. Doing this check here avoids self-imports as well. */ if (for_scanning) { bool nope = false; if (!per_cu->scanned.compare_exchange_strong (nope, true)) return nullptr; } ... is not actived. A quick experiment of setting it to true at the call site: ... diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c index 23fe5679cbd..f85263564cb 100644 --- a/gdb/dwarf2/read.c +++ b/gdb/dwarf2/read.c @@ -18143,7 +18143,7 @@ cooked_indexer::scan_attributes (dwarf2_per_cu_data *scanning_ per_cu, { cutu_reader *new_reader = ensure_cu_exists (reader, reader->cu->per_objfile, origin_offset, - origin_is_dwz, false); + origin_is_dwz, true); if (new_reader != nullptr) { const gdb_byte *new_info_ptr = (new_reader->buffer ... makes thread sanitizer stop complaining, but also makes the test-case fail: ... FAIL: gdb.dwarf2/inlined_subroutine-inheritance.exp: gdb_breakpoint: set breakpoint at bytes_repeat ... Thanks, - Tom > Tom> Fix this by guarding the write with a lock. > > I would rather we avoid locks. Ideally the existing exclusion mechanism > should be made to work, but if that fails, perhaps we can use another > atomic. > > Tom