[Bug gdb/24694] FAIL: gdb.multi/multi-arch-exec.exp: first_arch=1: selected_thread=1: follow_exec_mode=same: continue across exec that changes architecture (Couldn't get registers: No such process)

["simark at simark dot ca" <sourceware-bugzilla@sourceware.org>]

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

Simon Marchi <simark at simark dot ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simark at simark dot ca

--- Comment #8 from Simon Marchi <simark at simark dot ca> ---
This is due to an exec race.  We have two threads

- leader thread, doing the exec
- other thread, minding its own business

Things to remember are:

- GDB resumes threads one by one, one after the other
- When a multi-threaded program execs, regardless of which thread did the exec,
all non-leader threads disappear and it looks like the leader is now executing
the new executable.

When we do a "continue" after stopping at the all_started function, GDB tries
to resume leader first, then other.  In the failing case, leader has the time
to run its exec before GDB tries to resume the other thread.  So the ptrace
resume on the other thread fails with

  Couldn't get registers: No such process.

That aborts the resumption command and causes unexpected output, making the
test fail.

Since this particular test is not about testing this particular corner case, I
think we can avoid it by adding a synchronization point after the continue, so
the exec only happens after both threads were resumed.

But I also think we should handle the situation better.  When resuming multiple
threads and one of them fails with "no such process", we should probably print
a warning but carry on, not abort the continue.  There would be a separate test
for that (or whatever behavior we decide to have).

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