[Bug gdb/29286] SUMMARY: ThreadSanitizer: data race gdb/dwarf2/read.c:4100 in dw_expand_symtabs_matching_file_matcher

["vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

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

--- 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.

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