From owner-freebsd-current Tue May 8 20:32: 5 2001 Delivered-To: freebsd-current@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id BAFF037B423; Tue, 8 May 2001 20:32:01 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f493Vpf79731; Tue, 8 May 2001 23:31:51 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 8 May 2001 23:31:51 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: John Baldwin Cc: Dag-Erling Smorgrav , freebsd-current@FreeBSD.org, freebsd-stable@frebsd.org, Kris Kennaway , Dennis Glatting , tlambert2@mindspring.com Subject: Re: pgm to kill 4.3 via vm In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 8 May 2001, John Baldwin wrote: > That's easy enough. Well, it used to be at least. You can use 'ps' to > find the address of the struct proc (first pointer in the display) and > then do 'call psignal(addr, 9)' to send SIGKILL to the process. Then > hit 'c' to continue and voila, the process dies. I think that may panic > now due to proc lock not being held (though the debugger shouldn't need > any locks in theory.) Perhaps mtx_assert() should honor db_active and > not panic if it is set. I followed everything here fine until you asserted that the debugger shouldn't need any locks. I guess I don't see why that is, at least in terms of not corrupting structures. From a practical perspective, the debugger is like any other interupt-driven preemptive code-path: if you want to modify a structure, you need to synchronize appropriately to avoid corrupting the structure. This may not be something you really want to do in a debugger, so in that sense perhaps you *shouldn't* grab a lock in the debugger, but to perform the described action safely, you *should* grab a lock so as not to corrupt fields of the proc structure (i.e., if you broke into the debugger during a non-atomic flags update). Violating system invariants is something you should be allowed to do in a debugger, but this sounded like it was a feature people were looking from to recover from unhappy behavior, not to introduce it :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message