From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sourceware-bugzilla@sourceware.org>
Received: by sourceware.org (Postfix, from userid 48)
	id DD4273858C50; Tue,  3 Oct 2023 14:25:03 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DD4273858C50
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org;
	s=default; t=1696343103;
	bh=3dIv/Z/0j+tD8aV3aNv6ah3dANnDFg+0vmfVEQX1o3o=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=usfcqujepRDJ20ZSEiDfNJEwOhhETbJUtpTec4IpgIgysAZYHRSINxGPwMb00dhKr
	 voe+ym9PK8FmqSl94R9IwtwjnCt/Bv4net8df1VtsX+7Otm7GIEY9AKtY5rFrzdUcb
	 iyfY17aagHxGqDD4hXNUCGECmjZpC1n3V9nWi2No=
From: "simon.marchi at polymtl dot ca" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug gdb/30935] Regression exposed by new
 gdb.python/py-progspace-events.exp  test and native-extended-gdbserver board
Date: Tue, 03 Oct 2023 14:25:03 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gdb
X-Bugzilla-Component: gdb
X-Bugzilla-Version: HEAD
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: simon.marchi at polymtl dot ca
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: 14.1
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-30935-4717-5q5RaPuxW5@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-30935-4717@http.sourceware.org/bugzilla/>
References: <bug-30935-4717@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gdb-prs.sourceware.org>

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

--- 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 !=3D 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.  T=
he
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 w=
ant
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 complexit=
y 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 inferi=
ors,
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.

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