From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sourceware-bugzilla@sourceware.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 1F1903838788; Sat, 25 Jun 2022 12:14:03 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1F1903838788
From: "vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug gdb/29286] SUMMARY: ThreadSanitizer: data race
 gdb/dwarf2/read.c:4100 in dw_expand_symtabs_matching_file_matcher
Date: Sat, 25 Jun 2022 12:14:02 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gdb
X-Bugzilla-Component: gdb
X-Bugzilla-Version: HEAD
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vries at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-29286-4717-ZavJtGqAQq@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-29286-4717@http.sourceware.org/bugzilla/>
References: <bug-29286-4717@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: gdb-prs@sourceware.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gdb-prs mailing list <gdb-prs.sourceware.org>
List-Unsubscribe: <https://sourceware.org/mailman/options/gdb-prs>,
 <mailto:gdb-prs-request@sourceware.org?subject=unsubscribe>
List-Archive: <https://sourceware.org/pipermail/gdb-prs/>
List-Help: <mailto:gdb-prs-request@sourceware.org?subject=help>
List-Subscribe: <https://sourceware.org/mailman/listinfo/gdb-prs>,
 <mailto:gdb-prs-request@sourceware.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Jun 2022 12:14:03 -0000

https://sourceware.org/bugzilla/show_bug.cgi?id=3D29286

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #3)
> Hmm, AFAIU, building with 0 worker threads would guarantee this order, so
> the entry->per_cu->lang will then always be unknown when tested in
> cooked-index?

Not quite.  When building with 0 worker threads, I observed the following
order:
- prepare_one_comp_unit is called for the first time, and
  cu->per_cu->language is set
- in cooked_index::do_finalize, the cu->per_cu->language field is read
- then prepare_one_comp_unit is called once more, overwriting the
  cu->per_cu->language field with the same value

AFAICT, the race condition that thread sanitizer complains about is that the
second write happens after the read, but could happen before it.

I've tried only setting the the cu->per_cu->lang field if it's unknown, and
that seems to fix this particular problem.

But when re-introducing the bitfields, the original problem reappears.

--=20
You are receiving this mail because:
You are on the CC list for the bug.=