[Bug gdb/31713] New: race conditions in target simulation

[Bug gdb/31713] New: race conditions in target simulation

[bernd.edlinger at hotmail dot de]

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

            Bug ID: 31713
           Summary: race conditions in target simulation
           Product: gdb
           Version: HEAD
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: bernd.edlinger at hotmail dot de
  Target Milestone: ---

I have built a gdb/sim for riscv, and it is mostly working now,
but I tried to run test with thread sanitizer and it encountered race
conditons.
That are not there for target=host build:

with gdb.dwarf2/fission-multi-cu.exp I see
SUMMARY: ThreadSanitizer: data race ../../binutils-gdb/bfd/section.c:849 in
bfd_section_init

and with gdb.dwarf2/loclists-multiple-cus.exp I see twice a:
SUMMARY: ThreadSanitizer: data race ../../binutils-gdb/bfd/cache.c:283 in
bfd_cache_lookup_worker

likewise with gdb.dwarf2/loclists-start-end.exp.

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

[Bug gdb/31713] race conditions in target simulation

[bernd.edlinger at hotmail dot de]

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

--- Comment #1 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
Created attachment 15499
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15499&action=edit
tsan output from gdb.dwarf2/fission-multi-cu.exp

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

[Bug gdb/31713] race conditions in target simulation

[bernd.edlinger at hotmail dot de]

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

--- Comment #2 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
Created attachment 15500
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15500&action=edit
tsan output from gdb.dwarf2/loclists-multiple-cus.exp

This race condition happens twice in gdb.dwarf2/loclists-multiple-cus.exp
and almost completely identical twice in gdb.dwarf2/loclists-start-end.exp
therefore I only upload one tsan error report.

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

[Bug gdb/31713] race conditions in target simulation

[bernd.edlinger at hotmail dot de]

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

--- Comment #3 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
I have experimented with the following patch:

--- a/gdb/dwarf2/cooked-index.c
+++ b/gdb/dwarf2/cooked-index.c
@@ -644,8 +644,6 @@ cooked_index::set_contents (vec_type &&vec,
deferred_warnings *warn,
   gdb_assert (m_vector.empty ());
   m_vector = std::move (vec);

-  m_state->set (cooked_state::MAIN_AVAILABLE);
-
   /* This is run after finalization is done -- but not before.  If
      this task were submitted earlier, it would have to wait for
      finalization.  However, that would take a slot in the global
@@ -653,6 +651,7 @@ cooked_index::set_contents (vec_type &&vec,
deferred_warnings *warn,
      would cause a livelock.  */
   gdb::task_group finalizers ([=] ()
   {
+    m_state->set (cooked_state::MAIN_AVAILABLE);
     m_state->set (cooked_state::FINALIZED);
     m_state->write_to_cache (index_for_writing (), warn);
     m_state->set (cooked_state::CACHE_DONE);
~

The results are quite interesting.
As it stands it fixes all issues from #31715 and both
failures with the riscv simulation from this PR.
It does however not fix #31716.
BUT there are new failures, with the riscv simulation target,
but I am not able to pinpoint a single test case that triggers
them, they are not easy to reproduce, and happen randomly.

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

[Bug gdb/31713] race conditions in target simulation

[bernd.edlinger at hotmail dot de]

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

--- Comment #4 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
Created attachment 15511
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15511&action=edit
random data race in bfd_reinit

This happens randomly somewhere near gdb.dwarf2/fission*.exp

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

[Bug gdb/31713] race conditions in target simulation

[bernd.edlinger at hotmail dot de]

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

--- Comment #5 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
Created attachment 15512
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15512&action=edit
random data race in bfd_section_init

This happens also randomly near gdb.dwarf2/fission*.exp

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

[Bug gdb/31713] race conditions in target simulation

[bernd.edlinger at hotmail dot de]

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

--- Comment #6 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
Created attachment 15513
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15513&action=edit
random signal-unsafe call inside of a signal

This happens rarely in gdb.base/*.exp, this is actually two errors at once:
First there is a signal unsafe malloc/free happening in the signal handler,
but the reason is a segmentation fault in the "target sim" command.
I think this can only happen, because something with the bfd parser is not
stable, due to the underlying thread issue, that can make the simulator crash,
at least that is my theory.
The attachment contains only the TSAN output, but the gdb/testsuite/gdb.log
around the TSAN report reveals the reason why the signal was sent:

(gdb) target sim ^M 
^M 
^M 
[...many tsan errors reported here...]
Fatal signal: Segmentation fault^M
---- Backtrace -----^M
0x5608f46ad811 gdb_internal_backtrace_1^M
        ../../binutils-gdb/gdb/bt-utils.c:121^M
0x5608f46ad811 _Z22gdb_internal_backtracev^M
        ../../binutils-gdb/gdb/bt-utils.c:167^M
0x5608f48604e6 handle_fatal_signal^M
        ../../binutils-gdb/gdb/event-top.c:916^M
0x5608f486072c handle_sigsegv^M
        ../../binutils-gdb/gdb/event-top.c:989^M
0x7f84e843b3dc CallUserSignalHandler^M
        ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:2005^M
0x7f84e843b837 _Z10sighandleriPN11__sanitizer19__sanitizer_siginfoEPv^M
        ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:2085^M
0x7f84e7e5b04f ???^M
        ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0^M
0x5608f4c6b1e3 initialize_cpu^M
        ../../binutils-gdb/sim/riscv/sim-main.c:1584^M
0x5608f4c23227 sim_open^M
        ../../binutils-gdb/sim/riscv/interp.c:129^M
0x5608f4a226a7 gdbsim_target_open^M
        ../../binutils-gdb/gdb/remote-sim.c:744^M
0x5608f4b54744 open_target^M
        ../../binutils-gdb/gdb/target.c:837^M
0x5608f47000db _Z8cmd_funcP16cmd_list_elementPKci^M
        ../../binutils-gdb/gdb/cli/cli-decode.c:2741^M
0x5608f4b6f1ee _Z15execute_commandPKci^M
        ../../binutils-gdb/gdb/top.c:569^M
0x5608f4861e6a _Z15command_handlerPKc^M
        ../../binutils-gdb/gdb/event-top.c:579^M
0x5608f4863ed4
_Z20command_line_handlerOSt10unique_ptrIcN3gdb13xfree_deleterIcEEE^M
        ../../binutils-gdb/gdb/event-top.c:815^M
0x5608f486172c gdb_rl_callback_handler^M
        ../../binutils-gdb/gdb/event-top.c:271^M
0x5608f4cba39b rl_callback_read_char^M
        ../../../binutils-gdb/readline/readline/callback.c:290^M
0x5608f48610dd gdb_rl_callback_read_char_wrapper_noexcept^M
        ../../binutils-gdb/gdb/event-top.c:196^M
0x5608f4861453 gdb_rl_callback_read_char_wrapper^M
        ../../binutils-gdb/gdb/event-top.c:235^M
0x5608f4b9767f stdin_event_handler^M
        ../../binutils-gdb/gdb/ui.c:154^M
0x5608f4e4a545 handle_file_event^M
        ../../binutils-gdb/gdbsupport/event-loop.cc:551^M
0x5608f4e4ac4a gdb_wait_for_event^M
        ../../binutils-gdb/gdbsupport/event-loop.cc:672^M
0x5608f4e4b66b _Z16gdb_do_one_eventi^M
        ../../binutils-gdb/gdbsupport/event-loop.cc:263^M
0x5608f4960069 start_event_loop^M
        ../../binutils-gdb/gdb/main.c:401^M
0x5608f4960069 captured_command_loop^M
        ../../binutils-gdb/gdb/main.c:465^M
0x5608f4963f04 captured_main^M
        ../../binutils-gdb/gdb/main.c:1339^M
0x5608f4963f04 _Z8gdb_mainP18captured_main_args^M
        ../../binutils-gdb/gdb/main.c:1358^M
0x5608f45abab4 main^M
        ../../binutils-gdb/gdb/gdb.c:38^M
---------------------^M
[...more identical tsan errors reported here...]
A fatal error internal to GDB has been detected, further^M
debugging is not possible.  GDB will now terminate.^M
^M
  For instructions, see:^M
<https://www.gnu.org/software/gdb/bugs/>.^M
^M
ERROR: : spawn id exp9 not open
    while executing
"expect {
-i exp9 -timeout 2400
        -re ".*$gdb_prompt $" {
            if {$verbose > 1} {
                send_user "Loaded $arg into $GDB\n"
            }
            return 0
        }
        -re "..."
    ("uplevel" body line 1)
    invoked from within
"uplevel $body" NONE : spawn id exp9 not open
Couldn't send delete breakpoints to GDB.
UNRESOLVED: gdb.base/utf8-identifiers.exp: delete all breakpoints, watchpoints,
tracepoints, and catchpoints in delete_breakpoints

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

[Bug gdb/31713] race conditions in target simulation

[bernd.edlinger at hotmail dot de]

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

--- Comment #7 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
note in the above callstack, I used a couple of patches
to make the risv simulator run at all, so especially
the line number sim-main.c:1584 might be dependent on my patches.
in my source code it is this line here:

void
initialize_cpu (SIM_DESC sd, SIM_CPU *cpu, int mhartid)
{
  struct riscv_sim_cpu *riscv_cpu = RISCV_SIM_CPU (cpu);
  const char *extensions;
  int i;

  memset (riscv_cpu->regs, 0, sizeof (riscv_cpu->regs)); //<-- line 1584

  CPU_PC_FETCH (cpu) = pc_get;
  CPU_PC_STORE (cpu) = pc_set;
  CPU_REG_FETCH (cpu) = reg_fetch;
  CPU_REG_STORE (cpu) = reg_store;

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

[Bug gdb/31713] race conditions in target simulation

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |31751
                 CC|                            |tromey at sourceware dot org


Referenced Bugs:

https://sourceware.org/bugzilla/show_bug.cgi?id=31751
[Bug 31751] re-enable background DWARF reading
-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31713] race conditions in target simulation

[tromey at sourceware dot org]

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

--- Comment #8 from Tom Tromey <tromey at sourceware dot org> ---
Can you try the dwarf synchronous change for this one?
https://sourceware.org/pipermail/gdb-patches/2024-May/209267.html

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

[Bug gdb/31713] race conditions in target simulation

[bernd.edlinger at hotmail dot de]

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

--- Comment #9 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
Confirmed. The races are no longer reproducible with your patch.

However the signal unsafe call is potentially still there.
I debugged the signal handler, and I think this issue
is triggered by these statements:
  if (bt_on_fatal_signal)
    {
      sig_write ("\n\n");
      sig_write (_("Fatal signal: "));
      sig_write (strsignal (sig));
      sig_write ("\n");

the _() is not signal safe, but that is hard to detect,
because it does not trigger when on LANG=C is used,
and the test runs do this probably most of the time, to be
able to parse the output.
But when LANG=something else, even "en_US.UTF-8"
the signal unsafe warnings do occur.
just start gdb with tsan instrumentation, and
do kill -11 <pid> in a different terminal.
Do the same with LANG=C and the issue is not there.

This _() expands to a call to gettext, note that this
function calls stuff like pthread_rwlock_rdlock
which is not detected by tsan, but is obviously
not a good idea for a signal handler either.

But even strsignal is not thread safe, and uses _()
to translate the signal name.  The strsignal from libibery
is not used, but instead the glibc variant,
which calls _() to translate known signal names, and uses
malloc for signals from SIGRTMIN..SIGRTMAX.

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

[Bug gdb/31713] race conditions in target simulation

[tromey at sourceware dot org]

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

--- Comment #10 from Tom Tromey <tromey at sourceware dot org> ---
Some of the races here don't really seem possible.
Maybe they are false reports from TSAN.

Some do seem possible though.
Maybe the fix for bug#31626 will help with some.
I didn't realize gdb passes the exec BFD directly
to the sim:

  gdbsim_desc = sim_open (SIM_OPEN_DEBUG, &gdb_callback,
                          current_program_space->exec_bfd (), sim_argv);

so that might conceivably cause other issues depending
on exactly what the sim does.

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

[Bug gdb/31713] race conditions in target simulation

[tromey at sourceware dot org]

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

--- Comment #11 from Tom Tromey <tromey at sourceware dot org> ---
Also I don't think I have a good way to build a program that
can be loaded by the sim.  Could you attach a small riscv
executable that I can use?  It doesn't have to be runnable,
it's enough to have debuginfo & be loadable.

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

[Bug gdb/31713] race conditions in target simulation

[bernd.edlinger at hotmail dot de]

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

--- Comment #12 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
Created attachment 15753
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15753&action=edit
riscv sample executable file

$ riscv-unknown-elf-gcc -g -O2 hello.c -o hello
$ riscv-unknown-elf-run hello
hello riscv
$ cat hello.c 
#include <stdio.h>

int main()
{
  printf("hello riscv\n");
}

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

[Bug gdb/31713] race conditions in target simulation

[tromey at sourceware dot org]

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

--- Comment #13 from Tom Tromey <tromey at sourceware dot org> ---
Thanks.

I built a tsan gdb with --target=riscv-elf.
Then I ran gdb and 'source'd this script:

file /tmp/hello
target sim
load


This does not generate a tsan report for me.
Does it for you?

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

[Bug gdb/31713] race conditions in target simulation

[bernd.edlinger at hotmail dot de]

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

--- Comment #14 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
(In reply to Tom Tromey from comment #13)
> Thanks.
> 
> I built a tsan gdb with --target=riscv-elf.
> Then I ran gdb and 'source'd this script:
> 
> file /tmp/hello
> target sim
> load
> 
> 
> This does not generate a tsan report for me.
> Does it for you?

no there is no tsan report here.
But I ran the full testsuite and there are those:

$ grep '\(SUMM\|FAIL\|PASS\)' gdb/testsuite/gdb.log | grep -C1 SUMM
(gdb) PASS: gdb.base/finish.exp: Ensure return value was properly saved
SUMMARY: ThreadSanitizer: data race ../../binutils-gdb/bfd/section.c:842 in
bfd_section_init
SUMMARY: ThreadSanitizer: data race ../../binutils-gdb/bfd/section.c:849 in
bfd_section_init
(gdb) PASS: gdb.base/fission-macro.exp: dwarf_version=5: dwarf_bits=32:
strict_dwarf=0: No complaints
--
(gdb) FAIL: gdb.base/fission-macro.exp: dwarf_version=5: dwarf_bits=32:
strict_dwarf=0: info macro FOURTH
SUMMARY: ThreadSanitizer: data race ../../binutils-gdb/bfd/section.c:849 in
bfd_section_init
SUMMARY: ThreadSanitizer: data race ../../binutils-gdb/bfd/section.c:849 in
bfd_section_init
(gdb) PASS: gdb.base/fission-macro.exp: dwarf_version=5: dwarf_bits=32:
strict_dwarf=1: No complaints
--
(gdb) PASS: gdb.dwarf2/fission-absolute-dwo.exp: p global_var
SUMMARY: ThreadSanitizer: data race ../../binutils-gdb/bfd/format.c:199 in
bfd_reinit
(gdb) PASS: gdb.dwarf2/fission-mix.exp: break -q main
--
(gdb) PASS: gdb.dwarf2/fission-multi-cu.exp: frame in func
SUMMARY: ThreadSanitizer: data race ../../binutils-gdb/bfd/format.c:199 in
bfd_reinit
SUMMARY: ThreadSanitizer: data race ../../binutils-gdb/bfd/section.c:849 in
bfd_section_init
(gdb) PASS: gdb.dwarf2/fission-relative-dwo.exp: p global_var
--
(gdb) PASS: gdb.dwarf2/loc-sec-offset.exp: is_64=true: at func2: print /x foo
SUMMARY: ThreadSanitizer: data race ../../binutils-gdb/bfd/cache.c:283 in
bfd_cache_lookup_worker
(gdb) PASS: gdb.dwarf2/loclists-multiple-cus.exp: is_64=false: continue to
breakpoint: func1
--
(gdb) PASS: gdb.dwarf2/loclists-multiple-cus.exp: is_64=false: at func2: print
/x foo
SUMMARY: ThreadSanitizer: data race ../../binutils-gdb/bfd/cache.c:283 in
bfd_cache_lookup_worker
(gdb) PASS: gdb.dwarf2/loclists-multiple-cus.exp: is_64=true: continue to
breakpoint: func1
--
(gdb) PASS: gdb.dwarf2/loclists-sec-offset.exp: is_64=true: at func6: print /x
baz
SUMMARY: ThreadSanitizer: data race ../../binutils-gdb/bfd/cache.c:283 in
bfd_cache_lookup_worker
(gdb) PASS: gdb.dwarf2/loclists-start-end.exp: is_64=false: continue to
breakpoint: func1
--
(gdb) PASS: gdb.dwarf2/loclists-start-end.exp: is_64=false: at func2: print /x
foo
SUMMARY: ThreadSanitizer: data race ../../binutils-gdb/bfd/cache.c:283 in
bfd_cache_lookup_worker
(gdb) PASS: gdb.dwarf2/loclists-start-end.exp: is_64=true: continue to
breakpoint: func1

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

[Bug gdb/31713] race conditions in target simulation

[bernd.edlinger at hotmail dot de]

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

--- Comment #15 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
so something this test case does triggers the issue,
the majority of all test cases work just fine.
I've re-built everything with recent gcc/gdb sources.
and changed the dwarf_synchornous to false:
diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
index c2127c4d573..298289c5e2e 100644
--- a/gdb/dwarf2/read.c
+++ b/gdb/dwarf2/read.c
@@ -740,7 +740,7 @@ show_dwarf_max_cache_age (struct ui_file *file, int
from_tty,
 }

 /* When true, wait for DWARF reading to be complete.  */
-static bool dwarf_synchronous = true;
+static bool dwarf_synchronous = false;

 /* "Show" callback for "maint set dwarf synchronous".  */
 static void

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

[Bug gdb/31713] race conditions in target simulation

[tromey at sourceware dot org]

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

--- Comment #16 from Tom Tromey <tromey at sourceware dot org> ---
I can't run the tests in this configuration.
Maybe seeing a gdb.log from one of the failing tests would help
me reduce this to something I can try locally.

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

[Bug gdb/31713] race conditions in target simulation

[bernd.edlinger at hotmail dot de]

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

--- Comment #17 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
Created attachment 15762
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15762&action=edit
gdb log with tsan errors

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

[Bug gdb/31713] race conditions in target simulation

[tromey at sourceware dot org]

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

--- Comment #18 from Tom Tromey <tromey at sourceware dot org> ---
Well, this is terrible.  I missed a global when adding thread-safety
to BFD:

/* Unique section id.  */
extern unsigned int _bfd_section_id ATTRIBUTE_HIDDEN;

What's especially bad about this one is that it is used
to size something for the linker, apparently.
See bfd/elf64-ppc.c:

  htab->sec_info_arr_size = _bfd_section_id;

Also, worse, this variable is saved and preserved by
bfd_preserve_save and friends.

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

[Bug gdb/31713] race conditions in target simulation

[tromey at sourceware dot org]

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

--- Comment #19 from Tom Tromey <tromey at sourceware dot org> ---
https://sourceware.org/pipermail/binutils/2024-October/137419.html

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

[Bug gdb/31713] race conditions in target simulation

[cvs-commit at gcc dot gnu.org]

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

--- Comment #20 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Bernd Edlinger <edlinger@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7ffd4868a7e22dd2f8126822501bfa18479d715c

commit 7ffd4868a7e22dd2f8126822501bfa18479d715c
Author: Bernd Edlinger <bernd.edlinger@hotmail.de>
Date:   Mon May 20 07:12:30 2024 +0200

    Fix signal unsafe call inside a signal

    It can easily happen that the signal handler function
    `handle_fatal_signal` uses various signal unsafe functions.
    The problematic functions are `_` and `strsignal` which
    can be pre-computed after the `setlocale` call is done.

    Unfortunately when compiled with --disable-libbacktrace a
    different code path is used, that calls the glibc function
    `backtrace` which calls `malloc` and `free` and is therefore
    also signal unsafe, that is probably unfixable, so there
    is no attempt to fix anything in this code path.

    Approved-By: Andrew Burgess <aburgess@redhat.com>

    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31713#c9

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

[Bug gdb/31713] race conditions in target simulation

[tromey at sourceware dot org]

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

--- Comment #21 from Tom Tromey <tromey at sourceware dot org> ---
Created attachment 15778
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15778&action=edit
the patch

Could you try this patch?
I can't reproduce the failure but I suspect this will help.

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

[Bug gdb/31713] race conditions in target simulation

[bernd.edlinger at hotmail dot de]

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

--- Comment #22 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
OK, looks like an improvement, but some tsan errors remain:

$ grep SUMM gdb/testsuite/gdb.log 
SUMMARY: ThreadSanitizer: data race ../../binutils-gdb/bfd/cache.c:283 in
bfd_cache_lookup_worker
SUMMARY: ThreadSanitizer: data race ../../binutils-gdb/bfd/cache.c:283 in
bfd_cache_lookup_worker
SUMMARY: ThreadSanitizer: data race ../../binutils-gdb/bfd/cache.c:283 in
bfd_cache_lookup_worker
SUMMARY: ThreadSanitizer: data race ../../binutils-gdb/bfd/cache.c:283 in
bfd_cache_lookup_worker

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

[Bug gdb/31713] race conditions in target simulation

[vries at gcc dot gnu.org]

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

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vries at gcc dot gnu.org

--- Comment #23 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Bernd Edlinger from comment #22)
> OK, looks like an improvement, but some tsan errors remain:
> 
> $ grep SUMM gdb/testsuite/gdb.log 
> SUMMARY: ThreadSanitizer: data race ../../binutils-gdb/bfd/cache.c:283 in
> bfd_cache_lookup_worker
> SUMMARY: ThreadSanitizer: data race ../../binutils-gdb/bfd/cache.c:283 in
> bfd_cache_lookup_worker
> SUMMARY: ThreadSanitizer: data race ../../binutils-gdb/bfd/cache.c:283 in
> bfd_cache_lookup_worker
> SUMMARY: ThreadSanitizer: data race ../../binutils-gdb/bfd/cache.c:283 in
> bfd_cache_lookup_worker

Can you attach a gdb log with tsan errors?

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

[Bug gdb/31713] race conditions in target simulation

[tromey at sourceware dot org]

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

--- Comment #24 from Tom Tromey <tromey at sourceware dot org> ---
> OK, looks like an improvement, but some tsan errors remain:

Thanks.  This looks like a separate issue similar to
commit ce61f407.  Though maybe a nicer fix would
be to have reopen_exec_file wait for the reader to
finish.

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

[Bug gdb/31713] race conditions in target simulation

[tromey at sourceware dot org]

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

--- Comment #25 from Tom Tromey <tromey at sourceware dot org> ---
> Can you attach a gdb log with tsan errors?

There are some matching this in the existing attached log FWIW.

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

[Bug gdb/31713] race conditions in target simulation

[tromey at sourceware dot org]

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

--- Comment #26 from Tom Tromey <tromey at sourceware dot org> ---
I have fixes for both the problems pointed out here.
I'll attach the other one for testing soon.

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

[Bug gdb/31713] race conditions in target simulation

[tromey at sourceware dot org]

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

--- Comment #27 from Tom Tromey <tromey at sourceware dot org> ---
Created attachment 15790
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15790&action=edit
patch 2

Another patch that should help.

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

[Bug gdb/31713] race conditions in target simulation

[bernd.edlinger at hotmail dot de]

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

--- Comment #28 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
(In reply to Tom Tromey from comment #27)
> Created attachment 15790 [details]
> patch 2
> 
> Another patch that should help.

Ok, I've run the full test suite twice, and I can
confirm that all race conditions are fixed now.


Thanks
Bernd.

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

[Bug gdb/31713] race conditions in target simulation

[cvs-commit at gcc dot gnu.org]

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

--- Comment #29 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom Tromey <tromey@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=e1093de6a0feeb44a6a2f3bb4509d35eb28bcb66

commit e1093de6a0feeb44a6a2f3bb4509d35eb28bcb66
Author: Tom Tromey <tom@tromey.com>
Date:   Fri Nov 1 17:19:20 2024 -0600

    Fix races involving _bfd_section_id

    BFD's threading approach is that global variables are guarded by a
    lock.  However, while implementing this, I missed _bfd_section_id.  A
    user pointed out, via Thread Sanitizier, that this causes a data race
    when gdb's background DWARF reader is enabled.

    This patch fixes the problem by using the BFD lock in most of the
    appropriate spots.  However, in ppc64_elf_setup_section_lists I chose
    to simply assert that multiple threads are not in use instead.  (Not
    totally sure if this is good, but I don't think this can be called by
    gdb.)

    I chose locking in bfd_check_format_matches, even though it is a
    relatively big hammer, because it seemed like the most principled
    approach, and anyway if this causes severe contention we can always
    revisit the decision.  Also this approach means we don't need to add
    configury to check for _Atomic, or figure out whether bfd_section_init
    can be reworded to make "rollback" unnecessary.

    I couldn't reproduce these data races but the original reporter tested
    the patch and confirms that it helps.

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

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

[Bug gdb/31713] race conditions in target simulation

[cvs-commit at gcc dot gnu.org]

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

--- Comment #30 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom Tromey <tromey@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=a357defdfe2af758d5ec9f0040949bf1db4cbe53

commit a357defdfe2af758d5ec9f0040949bf1db4cbe53
Author: Tom Tromey <tom@tromey.com>
Date:   Sat Nov 9 13:45:50 2024 -0700

    Lock bfd_stat and bfd_get_mtime

    PR gdb/31713 points out some races when using the background DWARF
    reader.

    This particular patch fixes some of these, namely the ones when using
    the sim.  In this case, the 'load' command calls reopen_exec_file,
    which calls bfd_stat, which introduces a race.

    BFD only locks globals -- concurrent use of a single BFD must be
    handled by the application.  To this end, this patch adds locked
    wrappers for bfd_stat and bfd_get_mtime.

    I couldn't reproduce these data races but the original reporter tested
    the patch and confirms that it helps.

    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31713
    Approved-By: Andrew Burgess <aburgess@redhat.com>

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

[Bug gdb/31713] race conditions in target simulation

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |16.1

--- Comment #31 from Tom Tromey <tromey at sourceware dot org> ---
Should be fixed now.

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