From owner-freebsd-current Sun Mar 24 9:34:27 2002 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 E59FE37B417; Sun, 24 Mar 2002 09:34:17 -0800 (PST) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.6) with SMTP id g2OHY9k76843; Sun, 24 Mar 2002 12:34:10 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sun, 24 Mar 2002 12:34:08 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp Cc: "M. Warner Losh" , current@FreeBSD.ORG, obrien@FreeBSD.ORG Subject: Re: turning off malloc's AJ by default In-Reply-To: <62766.1016989834@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 24 Mar 2002, Poul-Henning Kamp wrote: > In message , Robe > rt Watson writes: > > >A few weeks ago, I would have believed you. Except that using -J was a > >workaround recommended in a recent security advisory--prior to > >recommending it, I ran it on a server of mine for a few days. You'd be > >surprised how many random applications keel over, and the performance > >impact it has for some specific types of applications. > > No, I will not be surprised no matter what you tell me. I used to keep > save all emails I got about phkmalloc nailing bugs, now I only track > "significant" ones. > > But let me turn it around, what would it take for you to accept AJ in > the developer release ? Better diagnostics ? Hmm. The argument for A is, I think, is a lot stronger than for J, since it comes without the performance impact, and you can actually generate useful diagnostics. I would be fine with leaving A in the developer snapshot. On the issue of making diagnostics more useful: sending this debugging information to syslog might be one way. The 'abort' already ends up on the console and in the log: Mar 24 12:25:39 paprika kernel: pid 52818 (tmp), uid 1000: exited on signal 6 (core dumped) Making that more informative might be helpful. I.e., Mar 24 12:25:39 paprika tmp: pid 52818: application error, double free(), aborting. Mar 24 12:25:39 paprika kernel: pid 52818 (tmp), uid 1000: exited on signal 6 (core dumped) would probably go a long way. This addresses the problem of "stderr lost for some or another reason, but the kernel message remains". On the other hand, it does introduce some potential recursion/reentrancy issues. I like the impact of J from the perspective of an application developer knowingly specifically turning it on, but part of the general problem with J is that the failure detection occurs as part of the application code, rather than specifically in a system library that can provide improved reporting. For example: ckimail is a command line IMAP tool which scans a set of IMAP mailboxes. It contains a bug (I assume) involving use of memory following a free(). With J turned on, it segfaults almost immediately on start (very soon after execve() completes). I'd like to be able to distinguish between bugs caused by this type of improved application debugging, and bugs generated by incorrect stack and signal handling, etc, which have the same failure mode (Segmentation Violation, Core Dumped). Other than playing electric fence-like games with memory protection and signal handlers (or heavy instrumentation in the form of purify), it's not clear to me how catching free'd memory use maps into specific reporting output. 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