[Bug gdb/28942] Problem with breakpoint condition calling a function in multi-threaded program

["aburgess at redhat dot com" <sourceware-bugzilla@sourceware.org>]

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

Andrew Burgess <aburgess at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
                 CC|                            |aburgess at redhat dot com
   Last reconfirmed|                            |2022-03-04
     Ever confirmed|0                           |1

--- Comment #1 from Andrew Burgess <aburgess at redhat dot com> ---
Wow, it's a small world.  I literally  just started looking at this same issue
this week.

The whole thread not marked resumed issue is fixed by this excellent patch:

  https://sourceware.org/pipermail/gdb-patches/2022-January/185109.html

Which you know as you already posted a link to this bug to that thread.

However, there are so many other problem related to this issue.

The first thing I noticed is that run_inferior_call calls clear_proceed_status,
which in all-stop mode calls clear_proceed_status_thread for each thread.

Once the above patch is merged I plan to add an assert to
clear_proceed_status_thread that the thread we are clearing is not resumed and
not executing.

Currently the not-executing assert will fail, but (due to the above patch being
missing) the not-resumed assert will only fail sometimes.

If we ignore the clear_proceed_status issue, then with the above patch the
resumed flag will be correct, and GDB will not try to start the already resumed
threads as part of the inferior call.

However, after the call, as we're in all-stop mode, GDB will stop all threads.

However, if the breakpoint condition doesn't segfault, but instead just returns
false, then GDB will resume the single thread that stopped for the breakpoint -
leaving all the other threads stopped.

I'm currently working on the idea that when we evaluate the breakpoint
condition we temporarily place GDB into non-stop mode, this would mean that,
when we evaluate the b/p condition we only restart the one thread, and
afterwards, we only expect the one thread to stop, but I need to do lots more
testing yet - maybe this is a really bad idea.

The only other option I can think of is to somehow have the infcall code figure
out that we are in all-stop mode, but some threads are already running.  Then,
after making the inferior call we only stop the set of threads that we started.
 However, this has a massive problem; how to handle new threads?

I'll clean up my correct patch and post it to this bug later today in case
anyone wants to try it.  I'll also add your crashing function test to my
working branch to make sure that is handled too.

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