From: Tom Tromey <tom@tromey.com>
To: Tom de Vries <tdevries@suse.de>
Cc: gdb-patches@sourceware.org, Tom Tromey <tom@tromey.com>
Subject: Re: [PATCH 5/5] [gdb/symtab] Fix data race on per_cu->lang
Date: Mon, 04 Jul 2022 12:30:17 -0600 [thread overview]
Message-ID: <877d4svih2.fsf@tromey.com> (raw)
In-Reply-To: <20220629152914.13149-5-tdevries@suse.de> (Tom de Vries's message of "Wed, 29 Jun 2022 17:29:14 +0200")
>>>>> "Tom" == Tom de Vries <tdevries@suse.de> 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?
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
next prev parent reply other threads:[~2022-07-04 18:30 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-29 15:29 [PATCH 1/5] [COVER-LETTER, RFC] Fix some fsanitize=thread issues in gdb's cooked index Tom de Vries
2022-06-29 15:29 ` [PATCH 2/5] [gdb/symtab] Fix data race on per_cu->dwarf_version Tom de Vries
2022-07-01 11:16 ` Tom de Vries
2022-07-02 11:07 ` Tom de Vries
2022-07-04 18:51 ` Tom Tromey
2022-07-04 19:43 ` Tom de Vries
2022-07-04 19:53 ` Tom Tromey
2022-06-29 15:29 ` [PATCH 3/5] [gdb/symtab] Work around fsanitize=address false positive for per_cu->lang Tom de Vries
2022-06-29 17:38 ` Pedro Alves
2022-06-29 18:25 ` Pedro Alves
2022-06-29 18:28 ` Pedro Alves
2022-07-04 7:04 ` [PATCH 3/5] [gdb/symtab] Work around fsanitize=address false positive for per_ cu->lang Tom de Vries
2022-07-04 18:32 ` [PATCH 3/5] [gdb/symtab] Work around fsanitize=address false positive for per_cu->lang Tom Tromey
2022-07-04 19:45 ` Tom de Vries
2022-07-06 19:20 ` [PATCH] Introduce struct packed template, fix -fsanitize=thread for per_cu fields Pedro Alves
2022-07-07 10:18 ` Tom de Vries
2022-07-07 15:26 ` Pedro Alves
2022-07-08 14:54 ` Tom de Vries
2022-07-12 10:22 ` Tom de Vries
2022-06-29 15:29 ` [PATCH 4/5] [gdb/symtab] Work around fsanitize=address false positive for per_cu->unit_type Tom de Vries
2022-06-29 15:29 ` [PATCH 5/5] [gdb/symtab] Fix data race on per_cu->lang Tom de Vries
2022-07-04 18:30 ` Tom Tromey [this message]
2022-07-05 8:17 ` Tom de Vries
2022-07-05 15:19 ` Tom de Vries
2022-07-06 15:42 ` Tom de Vries
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877d4svih2.fsf@tromey.com \
--to=tom@tromey.com \
--cc=gdb-patches@sourceware.org \
--cc=tdevries@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).