[Bug gdb/30935] Regression exposed by new gdb.python/py-progspace-events.exp test and native-extended-gdbserver board

["simon.marchi at polymtl dot ca" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #3 from Simon Marchi <simon.marchi at polymtl dot ca> ---
One thing that is really fishy in ~current_program_space:

We have this to ensure the program space being deleted is not current:

  gdb_assert (this != current_program_space);

But we also have this that relies on the current inferior:

  if (!gdbarch_has_shared_address_space (target_gdbarch ()))
    delete this->aspace;

So let's say you have two inferiors, connected to two different targets.  The
current inferior is inferior 1, and you do "remove-inferiors 2".  We'll get the
has_shared_address_spaces property from inferior 1's arch, even though we want
to query about inferior 2's arch.

I spotted this because the crash happens inside this
gdbarch_has_shared_address_space.

I wonder if we can just make program_space::aspace a shared_ptr, it would
auto-delete the aspace when there are no more users, removing the complexity of
deciding when to delete it.  Also, as it stands, we never delete the aspace (I
think) if gdbarch_has_shared_address_space is true.  So imagine you connect to
a remote where gdbarch_has_shared_address_space is true, debug a few inferiors,
then disconnect.  I guess we will possibly have created an aspace and never
deleted it.  Using a shared_ptr would take care of that.  Oh, and would also
fix the crash reported in this bug.

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