Re: turning off malloc's AJ by default
On Sat, 23 Mar 2002, M. Warner Losh wrote: In message: [EMAIL PROTECTED] David O'Brien [EMAIL PROTECTED] writes: : The RE's are wanting to ship 5.0 DP#1 w/this patch applied. : If having 'AJ' by default is deemed not useful (by being removed from the : DP), it sounds like we should just turn it off. : : Unless there is strong objection, I plan on committing this. I think we should keep AJ enabled until at least DP2. It has found bugs in the past, and I suspect that a lot of new code is going in between now and then. Not clear from your suggestion if you mean the branch or the dp's. My feeling is that a useful strategy is: - -CURRENT has AJ from inception of branch until final DP before release. - DP's don't have AJ AJ generates false positives in the form of third party application behavior changes. When we're replacing things like the threading model, etc, etc, I don't want application failures to be attributed to those feature changes when they originate from memory junking. DP's offer an opportunity for third party developers to explore the new feature set, make sure their applications work with the new primitives, etc. While forcing them to fix memory related bugs is a useful activity, doing it with the DP seems to be a less useful activity. Useful feedback: - New protection settings for signalling break (fooapp) - There appear to be thread problems related to file descriptors and KSE - Changes in mmap behavior result in some applications with custom memory management failing Unuseful feedback: - Some major application coredumps before it even pops up a window due to referencing memory after a free but before it's reallocated, resulting in ten or fifteen such bug reports - Some X11 application usually run without a terminal on stderr dies frequently due to violating a safety constraint; failure mode is reported to us and prevents people from running that application, meaning we don't learn about system bugs - Some applications become incredibly slow and have very high loads, so the DP can't be used out of the box for some server environments where we'd like it to be used to maximize load on the system. With new userland code coming into -CURRENT at a rapid rate, it may be useful in -CURRENT for developers. For DPs, probably not. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: turning off malloc's AJ by default
In message [EMAIL PROTECTED], Robe rt Watson writes: With new userland code coming into -CURRENT at a rapid rate, it may be useful in -CURRENT for developers. For DPs, probably not. I don't have to tell you what the 'D' in 'DP' means, right ? :-) Robert, I can only say that I disagree 100% with you. In principle because I think only -RELEASE should not have J, and I think even -RELEASE should have A. In practice I think this is completely l00ney, considering what we have done in the kernel, worrying about AJ related false hits is sooo totally down in the noise. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: turning off malloc's AJ by default
On Sun, Mar 24, 2002 at 11:28:27AM -0500, Robert Watson wrote: Not clear from your suggestion if you mean the branch or the dp's. My feeling is that a useful strategy is: - -CURRENT has AJ from inception of branch until final DP before release. - DP's don't have AJ The DP's should have what ever is in -CURRENT. I don't care which state that is. Should I also mention the DP's GENERIC kernel has no INVARIANTS and no WITNESS? I have not gotten a response back from the RE's about that one yet. This is also wrong. INVARIANTS is low-impact. I can kind of accept WITNESS -- maybe we should turn it off in GENERIC in -CURRENT. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: turning off malloc's AJ by default
On Sun, 24 Mar 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Robe rt Watson writes: With new userland code coming into -CURRENT at a rapid rate, it may be useful in -CURRENT for developers. For DPs, probably not. I don't have to tell you what the 'D' in 'DP' means, right ? :-) Robert, I can only say that I disagree 100% with you. In principle because I think only -RELEASE should not have J, and I think even -RELEASE should have A. In practice I think this is completely l00ney, considering what we have done in the kernel, worrying about AJ related false hits is sooo totally down in the noise. 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. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: turning off malloc's AJ by default
In message [EMAIL PROTECTED], 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 ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: turning off malloc's AJ by default
David O'Brien [EMAIL PROTECTED] writes: Should I also mention the DP's GENERIC kernel has no INVARIANTS and no WITNESS? I have not gotten a response back from the RE's about that one yet. This is also wrong. INVARIANTS is low-impact. I can kind of accept WITNESS -- maybe we should turn it off in GENERIC in -CURRENT. Agreed. Please turn on INVARIANTS by default in DP1; its impact on performance is minimal and it helps *a lot* in tracking down bugs. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: turning off malloc's AJ by default
On Sun, 24 Mar 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], 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 [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: turning off malloc's AJ by default
On Sun, Mar 24, 2002 at 12:34:08PM -0500, Robert Watson wrote: 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. Lets back up and clarify RE's goals for the DP#1. Turning off all of our debugging options and appearing to make this benchmark ready were not part of what I [thought I] heard at the Kernel Summit at BSDcon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: turning off malloc's AJ by default
On Sun, 24 Mar 2002, David O'Brien wrote: On Sun, Mar 24, 2002 at 12:34:08PM -0500, Robert Watson wrote: 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. Lets back up and clarify RE's goals for the DP#1. Turning off all of our debugging options and appearing to make this benchmark ready were not part of what I [thought I] heard at the Kernel Summit at BSDcon. The goal of DP's is to increase exposure of the development branch in some key audiences, including the developer community, and community of early adopters. Part of the discussion that lead up to deciding to follow through on the DP plan was the perception that many FreeBSD non-kernel developers are not running 5.0, and that 5.0 had a fear element that didn't seem to match with reality. A part of addressing this is to provide a window into which 4.x developers can try out 5.x with a lower level of risk: this is why we had something that resembled a code slush, and why when greenvm was committed during the code slush, we actually backed it out of the DP branch (it was later also backed out of the main development branch). We want to provide a stable and usable version of 5.0, in as much as that is possible, to provide access to the new features, services, APIs, etc. We want a reproduceable install that ports developers can use to learn more about the changing 5.0 environment, among other things. We will actually be offering at least three seperate kernels on the DP cd: - GENERIC, which resembles a normal release GENERIC - DEBUG, which has uber-debugging features - NEWCARD, which offers the NEWCARD feature set For future DPs, we'll lose the oldcard/newcard distinction so we'll cut that out of the offering as soon as that is possible. GENERIC will offer the user something that they can use easily and effectively from the install. DEBUG turns on many debugging features, and will provide an easy path to debug system problems without evening having to custom compile a kernel. Users will have the option of selecting maximal debugging to attempt to track down problems and test the system. They'll have the option to select Looks most like a release to use for application testing and porting, not to mention daily usage. Something that phk and I have discussed out-of-band is the idea of keying phkmalloc behavior to kernel selection. I.e., exposing a policy sysctl from the kernel, keyed to the kernel identity/option, causing phkmalloc to behave different based on the kernel selection. This would allow DEBUG to turn on maximal debugging, but GENERIC to have phkmalloc behave like a release. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: turning off malloc's AJ by default
In message [EMAIL PROTECTED], Robe rt Watson writes: Something that phk and I have discussed out-of-band is the idea of keying phkmalloc behavior to kernel selection. I.e., exposing a policy sysctl from the kernel, keyed to the kernel identity/option, causing phkmalloc to behave different based on the kernel selection. This would allow DEBUG to turn on maximal debugging, but GENERIC to have phkmalloc behave like a release. I said this as possible with a sysctl, I still think it is moderately disgusting though. You can do the same thing more visible by having /etc/rc* fiddle /etc/malloc.conf based on uname(1). We will actually be offering at least three seperate kernels on the DP cd: - GENERIC, which resembles a normal release GENERIC - DEBUG, which has uber-debugging features - NEWCARD, which offers the NEWCARD feature set I would expect the three planned DP's to have these properties: One DEBUG kernel with: INVARIANTS WITNESS DDB One GENERIC kernel with: INVARIANTS DDB Userland: DP1 + DP2: malloc AJ DP3: malloc A Now, I also have to say that I'm not going to do any of this, so this will be my last email on the topic: Do whatever you think is the right thing to do. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: turning off malloc's AJ by default
This seems like a reasonable strategy. If we do this, we'll need to expand the discussion of performance tuning and usability in the release notes for the DP. We'll also need to formalize the notion of DP3: right now we have only DP1 and DP2 formally scheduled, and DP2 is expected to have some bumps due to KSE hopefully becoming real for userland for that, and with the MAC code. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services On Sun, 24 Mar 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Robe rt Watson writes: Something that phk and I have discussed out-of-band is the idea of keying phkmalloc behavior to kernel selection. I.e., exposing a policy sysctl from the kernel, keyed to the kernel identity/option, causing phkmalloc to behave different based on the kernel selection. This would allow DEBUG to turn on maximal debugging, but GENERIC to have phkmalloc behave like a release. I said this as possible with a sysctl, I still think it is moderately disgusting though. You can do the same thing more visible by having /etc/rc* fiddle /etc/malloc.conf based on uname(1). We will actually be offering at least three seperate kernels on the DP cd: - GENERIC, which resembles a normal release GENERIC - DEBUG, which has uber-debugging features - NEWCARD, which offers the NEWCARD feature set I would expect the three planned DP's to have these properties: One DEBUG kernel with: INVARIANTS WITNESS DDB One GENERIC kernel with: INVARIANTS DDB Userland: DP1 + DP2: malloc AJ DP3: malloc A Now, I also have to say that I'm not going to do any of this, so this will be my last email on the topic: Do whatever you think is the right thing to do. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: turning off malloc's AJ by default
David O'Brien wrote: On Sun, Mar 24, 2002 at 12:34:08PM -0500, Robert Watson wrote: 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. Lets back up and clarify RE's goals for the DP#1. Turning off all of our debugging options and appearing to make this benchmark ready were not part of what I [thought I] heard at the Kernel Summit at BSDcon. I didn't hear that either, and it's starting to make me a little nervous. It's bad enough that the first DP will be almost wholely unlike what the 5.0-Release will actually look like, now it seems that its value will be further reduced by making it very different from -Current of the same time period. I see two major problems with that. First, it does little good for us to release something to a wider audience if it's not going to be what and how we're actually trying to test. The other major problem is that I really don't think many users are going to stick with the DP versions. When users complain about bugs in the DP's, they are going to be pointed to -Current. Then they are going to have to experience the learning curve anyway. I think a better solution would be to ship the DP's with the same defaults as -Current of the same vintage, and educate the users as to how to remove some of the debugging features. As others have said, this is supposed to be a DEVELOPER'S preview. Until we get closer to something that looks like a release, leaving the bar set a little higher benefits both us and our potential consumers. Doug -- We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory. - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: turning off malloc's AJ by default
On Sun, Mar 24, 2002 at 01:59:56PM -0500, Robert Watson wrote: The goal of DP's is to increase exposure of the development branch in some key audiences, including the developer community, and community of early adopters. Part of the discussion that lead up to deciding to follow through on the DP plan was the perception that many FreeBSD non-kernel developers are not running 5.0, and that 5.0 had a fear element that didn't seem to match with reality. A part of addressing this is to provide a window into which 4.x developers can try out 5.x with a lower level of risk: this is why we had something that resembled a code slush, and why when greenvm was committed during the code slush, we actually backed it out of the DP branch (it was later also backed out of the main development branch). We want to provide a stable and usable version of 5.0, in as much as that is possible, to provide access to the new features, services, APIs, etc. We want a reproduceable install that ports developers can use to learn more about the changing 5.0 environment, among other things. There is nothing in the above that motivates turning off 'AJ' and INVARIANTS. Please address these two issues based on the above which I do think is what was generally agreed as the motivation for the DP. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
turning off malloc's AJ by default
The RE's are wanting to ship 5.0 DP#1 w/this patch applied. If having 'AJ' by default is deemed not useful (by being removed from the DP), it sounds like we should just turn it off. Unless there is strong objection, I plan on committing this. Index: malloc.c === RCS file: /home/ncvs/src/lib/libc/stdlib/malloc.c,v retrieving revision 1.66 diff -u -u -1 -r1.66 malloc.c --- malloc.c22 Mar 2002 21:53:10 - 1.66 +++ malloc.c23 Mar 2002 23:52:40 - @@ -223,3 +223,3 @@ /* Abort(), user doesn't handle problems. */ -static int malloc_abort = 1; +static int malloc_abort; @@ -244,3 +244,3 @@ /* junk fill ? */ -static int malloc_junk = 1; +static int malloc_junk; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: turning off malloc's AJ by default
If I remember correctly, it was the plan all along that releases would not have AJ turned on by default. The real question is: should the patch stay in after the release is rolled? Has the AJ default outlived its usefulness in general? -Matt Matthew Dillon [EMAIL PROTECTED] :The RE's are wanting to ship 5.0 DP#1 w/this patch applied. :If having 'AJ' by default is deemed not useful (by being removed from the :DP), it sounds like we should just turn it off. : :Unless there is strong objection, I plan on committing this. : :Index: malloc.c :=== :RCS file: /home/ncvs/src/lib/libc/stdlib/malloc.c,v :retrieving revision 1.66 :diff -u -u -1 -r1.66 malloc.c :--- malloc.c 22 Mar 2002 21:53:10 - 1.66 :+++ malloc.c 23 Mar 2002 23:52:40 - :@@ -223,3 +223,3 @@ : /* Abort(), user doesn't handle problems. */ :-static int malloc_abort = 1; :+static int malloc_abort; : :@@ -244,3 +244,3 @@ : /* junk fill ? */ :-static int malloc_junk = 1; :+static int malloc_junk; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: turning off malloc's AJ by default
In message: [EMAIL PROTECTED] David O'Brien [EMAIL PROTECTED] writes: : The RE's are wanting to ship 5.0 DP#1 w/this patch applied. : If having 'AJ' by default is deemed not useful (by being removed from the : DP), it sounds like we should just turn it off. : : Unless there is strong objection, I plan on committing this. I think we should keep AJ enabled until at least DP2. It has found bugs in the past, and I suspect that a lot of new code is going in between now and then. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: turning off malloc's AJ by default
[ WARNING, From: let to the list to deal with ignorant MUA's ] On Sat, Mar 23, 2002 at 05:23:35PM -0700, M. Warner Losh wrote: David O'Brien [EMAIL PROTECTED] writes: : The RE's are wanting to ship 5.0 DP#1 w/this patch applied. : If having 'AJ' by default is deemed not useful (by being removed from the : DP), it sounds like we should just turn it off. : : Unless there is strong objection, I plan on committing this. I think we should keep AJ enabled until at least DP2. It has found bugs in the past, and I suspect that a lot of new code is going in between now and then. Robert Watson feels that AJ caught bugs early on, but now only catches buts in 3rd party programs. As FreeBSD developers, 3rd party code cannot be our primary concern. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: turning off malloc's AJ by default
In message: [EMAIL PROTECTED] [EMAIL PROTECTED] writes: : [ WARNING, From: let to the list to deal with ignorant MUA's ] Or MUA's that don't meet your expectations. : On Sat, Mar 23, 2002 at 05:23:35PM -0700, M. Warner Losh wrote: : David O'Brien [EMAIL PROTECTED] writes: : : The RE's are wanting to ship 5.0 DP#1 w/this patch applied. : : If having 'AJ' by default is deemed not useful (by being removed from the : : DP), it sounds like we should just turn it off. : : : : Unless there is strong objection, I plan on committing this. : : I think we should keep AJ enabled until at least DP2. It has found : bugs in the past, and I suspect that a lot of new code is going in : between now and then. : : Robert Watson feels that AJ caught bugs early on, but now only catches : buts in 3rd party programs. As FreeBSD developers, 3rd party code cannot : be our primary concern. With trustedbsd stuff coming in, and other userland things being imported from time to time, I think that it will still be useful for a time. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: turning off malloc's AJ by default
At 4:34 PM -0800 3/23/02, David wrote: On Sat, Mar 23, 2002 at 05:23:35PM -0700, M. Warner Losh wrote: I think we should keep AJ enabled until at least DP2. It has found bugs in the past, and I suspect that a lot of new code is going in between now and then. Robert Watson feels that AJ caught bugs early on, but now only catches buts in 3rd party programs. As FreeBSD developers, 3rd party code cannot be our primary concern. The recent bug I fixed in login processing (the LOGIN-FAILURES message) was a problem which was made obvious due to the J. I wouldn't mind if the A was turned off, but the J still seems useful to me. (disclaimer: I used to work on an operating system which *always* did something similar to J...) -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: turning off malloc's AJ by default
Well, 'current' has spoken I guess! :-) -Matt Matthew Dillon [EMAIL PROTECTED] :From: [EMAIL PROTECTED] :To: M. Warner Losh [EMAIL PROTECTED] :Cc: [EMAIL PROTECTED] :Subject: Re: turning off malloc's AJ by default :Message-ID: [EMAIL PROTECTED] :Reply-To: [EMAIL PROTECTED] :References: [EMAIL PROTECTED] :[EMAIL PROTECTED] : :[ WARNING, From: let to the list to deal with ignorant MUA's ] : :On Sat, Mar 23, 2002 at 05:23:35PM -0700, M. Warner Losh wrote: : David O'Brien [EMAIL PROTECTED] writes: : : The RE's are wanting to ship 5.0 DP#1 w/this patch applied. : : If having 'AJ' by default is deemed not useful (by being removed from the : : DP), it sounds like we should just turn it off. : : : : Unless there is strong objection, I plan on committing this. : : I think we should keep AJ enabled until at least DP2. It has found : bugs in the past, and I suspect that a lot of new code is going in : between now and then. : :Robert Watson feels that AJ caught bugs early on, but now only catches :buts in 3rd party programs. As FreeBSD developers, 3rd party code cannot :be our primary concern. : :To Unsubscribe: send mail to [EMAIL PROTECTED] :with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: turning off malloc's AJ by default
On 2002-03-23 17:10, Matthew Dillon wrote:
Well, 'current' has spoken I guess! :-)
:From: [EMAIL PROTECTED]
:To: M. Warner Losh [EMAIL PROTECTED]
Damn, I knew we shouldn't make current too smart.
Now we'll have to find names for 5.0-RELEASE like 'Wintermute' etc.
Giorgos Keramidas FreeBSD Documentation Project
keramida@{freebsd.org,ceid.upatras.gr} http://www.FreeBSD.org/docproj/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: turning off malloc's AJ by default
On Sat, Mar 23, 2002 at 04:09:27PM -0800, Matthew Dillon wrote: If I remember correctly, it was the plan all along that releases would not have AJ turned on by default. The real question is: should the patch stay in after the release is rolled? Has the AJ default outlived its usefulness in general? Well, I just reported a problem to NAG (www.nag.com) with their Fortran 95 compiler. The bug was found by phkmalloc and the AJ setting. NAG fixed the bug within 3 days and supplied a new binary. BTW, this is the only native Fortran 95 compiler for FreeBSD. I told NAG's tech support about the AJ feature and it appears NAG found at least one other bug with this set. I think AJ should be left set in the DP releases with a prominent note in the RELNOTES about the possible performance impact. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: turning off malloc's AJ by default
On Sat, Mar 23, 2002 at 04:34:57PM -0800, [EMAIL PROTECTED] wrote: As FreeBSD developers, 3rd party code cannot be our primary concern. Surely, you're joking. No wonder it's a PITA to convince a 3rd party vendor to release a FreeBSD product. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: turning off malloc's AJ by default
On Sat, Mar 23, 2002 at 06:40:21PM -0800, Steve Kargl wrote: On Sat, Mar 23, 2002 at 04:34:57PM -0800, [EMAIL PROTECTED] wrote: As FreeBSD developers, 3rd party code cannot be our primary concern. Surely, you're joking. No wonder it's a PITA to convince a 3rd party vendor to release a FreeBSD product. No I am not joking. I do not see what my statement in the context of `AJ' implies I do not care about 3rd party applications running on FreeBSD. However, a debugging option that at this point only finds bugs in 3rd party applications that exist on Linux, Solaris, etc.. also is not suffient reason to continue to penalize all FreeBSD users. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: turning off malloc's AJ by default
On Sat, Mar 23, 2002 at 06:40:21PM -0800, Steve Kargl wrote: Surely, you're joking. No wonder it's a PITA to convince a 3rd party vendor to release a FreeBSD product. Please don't misinterpret David's words. 3rd party apps are not our *primary* concern, FreeBSD is. And note that in this thread we are talking about turning the default off. This does not stop someone from turning AJ back on and using them to debug/fix a program. :-) Regards, -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: turning off malloc's AJ by default
In message [EMAIL PROTECTED], David O'Brien writes: The RE's are wanting to ship 5.0 DP#1 w/this patch applied. If having 'AJ' by default is deemed not useful (by being removed from the DP), it sounds like we should just turn it off. Unless there is strong objection, I plan on committing this. I firmly belive that only things which ship as FreeBSD-%d.%d-RELEASE should have the AJ options turned off. We want both our own code and 3rd party code to find the bugs in a DP release rather than in a RELEASE. Put a prominent notice in the release note, put a pointer to the recent libz scare if you feel like, and say that since this is about trying out and testing, we have set these options to help people flush out bugs. The steady trickle of emails I receive about things exposed by AJ is a clear indication that we need it on as much as possible. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
