[Bug build/29359] New: [gdb/build] Flush out thread sanitizer issues

[Bug build/29359] New: [gdb/build] Flush out thread sanitizer issues

[vries at gcc dot gnu.org]

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

            Bug ID: 29359
           Summary: [gdb/build] Flush out thread sanitizer issues
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: build
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

In PR29286 I ran into a few race condition that are now hard to reproduce, but
not fixed AFAICT.

See f.i. the patch at PR 29286 comment 6.

Which made me wonder which other race conditions are lurking.

I wonder if there's anything I can do to flush these out.

>From what I understand, the race conditions are due to executing this:
...
void
cooked_index::finalize ()
{
  m_future = gdb::thread_pool::g_thread_pool->post_task ([this] ()
    {
      do_finalize ();
    });
}
...
and not waiting for it, so perhaps adding a sleep () here could help?

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

[Bug build/29359] [gdb/build] Flush out thread sanitizer issues

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
I tried this:
...
diff --git a/gdb/dwarf2/cooked-index.c b/gdb/dwarf2/cooked-index.c
index adb0046609e..d8f5cfdcdbe 100644
--- a/gdb/dwarf2/cooked-index.c
+++ b/gdb/dwarf2/cooked-index.c
@@ -119,6 +119,7 @@ cooked_index::finalize ()
 {
   m_future = gdb::thread_pool::g_thread_pool->post_task ([this] ()
     {
+      usleep (1 * 1000 * 1000);
       do_finalize ();
     });
 }
...
but no results.

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

[Bug build/29359] [gdb/build] Flush out thread sanitizer issues

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
Another idea I had was to make sure that this in parallel_for:
...
  /* Process all the remaining elements in the main thread.  */
  return results.finish ([=] ()
    {
      return callback (first, last);
    });
...
is not run on the main thread, but only in the thread pool, to maximize the
skew between main thread and parallel for, but given that the parallel for
waits for the elements to finish, I don't expects any results from this
currently.

But if we start to use thread_local memory, this could be something useful to
try.

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

[Bug build/29359] [gdb/build] Flush out thread sanitizer issues

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

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


Referenced Bugs:

https://sourceware.org/bugzilla/show_bug.cgi?id=29366
[Bug 29366] [meta] New DWARF indexer meta bug
-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29359] [gdb/build] Flush out thread sanitizer issues

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #2)
> Another idea I had was to make sure that this in parallel_for:
> ...
>   /* Process all the remaining elements in the main thread.  */
>   return results.finish ([=] ()
>     {
>       return callback (first, last);
>     });
> ...
> is not run on the main thread, but only in the thread pool, to maximize the
> skew between main thread and parallel for, but given that the parallel for
> waits for the elements to finish, I don't expects any results from this
> currently.
> 
> But if we start to use thread_local memory, this could be something useful
> to try.

https://sourceware.org/pipermail/gdb-patches/2022-July/190830.html

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

[Bug build/29359] [gdb/build] Flush out thread sanitizer issues

[vries at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
   Target Milestone|---                         |13.1
         Resolution|---                         |FIXED

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #3)
> (In reply to Tom de Vries from comment #2)
> > Another idea I had was to make sure that this in parallel_for:
> > ...
> >   /* Process all the remaining elements in the main thread.  */
> >   return results.finish ([=] ()
> >     {
> >       return callback (first, last);
> >     });
> > ...
> > is not run on the main thread, but only in the thread pool, to maximize the
> > skew between main thread and parallel for, but given that the parallel for
> > waits for the elements to finish, I don't expects any results from this
> > currently.
> > 
> > But if we start to use thread_local memory, this could be something useful
> > to try.
> 
> https://sourceware.org/pipermail/gdb-patches/2022-July/190830.html

This was not deemed acceptable in review.

I've done all I could think of, so I'm marking this task done, even though
there are no actual resulting commits.

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