Date: Fri, 11 Jan 2002 00:33:01 -0800 From: "Ted Mittelstaedt" <tedm@toybox.placo.com> To: <gnb@itga.com.au> Cc: <freebsd-bugs@FreeBSD.ORG> Subject: RE: kern/33637: Panic: vm_page_unwire: invalid wire count: 0 Message-ID: <000201c19a7a$94a7d840$1401a8c0@tedm.placo.com> In-Reply-To: <200201102242.JAA15581@lightning.itga.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
>-----Original Message----- >From: gnb@itga.com.au [mailto:gnb@itga.com.au] >Sent: Thursday, January 10, 2002 2:42 PM >To: Ted Mittelstaedt >Cc: gnb@itga.com.au; freebsd-bugs@FreeBSD.ORG >Subject: Re: kern/33637: Panic: vm_page_unwire: invalid wire count: 0 > > >> The submitter of the PR >> was operating under a false assumption - that he could run any program and >> assume that it was impossible for it to crash the OS. > >But I don't think that is a false assumtion. On the contrary, that >is exactly >what I would expect and hope to find from a "production quality" OS like >FreeBSD. If you give a program life-and-death authority over the system and the program crashes the system then that is hardly a bug in the system, now is it? > >IMO the submitter was being entirely reasonable in making that >assumption - or >at least, on finding a violation of that assumption, to report it >and expect it >to be treated as a bug. (Even if the response is "we know it's a >bug and it's >hard to fix, here's a workaround using login.conf".) > But that WASN'T my response, re-read my response to the PR, I did not tell him to fix his problem with login.conf. I merely pointed him to it because he stated: "An application should not cause a kernel panic if it only uses the system calls documented in section 2 or the library functions documented in section 3 of the manual." which is obviously incorrect, and if he read the manpage to login.conf he would have realized this. I'm not ruling out a kernel bug. But the submitter had obviously ruled out an application bug without any reason to do so, and in fact when the preliminary evidence points to the application. This is unreasonable. >I guess we can agree to differ here, and I ain't nothing 'cept a user, but my >gut feel is that the wider FreeBSD team tends to my way of thinking >rather than >yours!!! I think your talking about a generalized philosophical stance not a specific case of debugging. I don't disagree with the philosophy but I don't think it applies in this specific case. The biggest problem with this PR is that the submitters attitude is wrong. Yes, the submitter has a real problem. Obviously he's frustrated. Obviously, in some piece of code somewhere, either in the application or in the OS, there's a bug that's causing this. But these sorts of bug reports are worthless to the FreeBSD team if the submitter is going to jump to conclusions that it's an OS bug and not even _try_ pursuing the possibility that it's an application bug. The fact that the server was fine for 6 months till the application program was loaded on it couldn't scream out "application bug" louder than if it was on the top of the mountain jumping up and down. Should a PR be put into the system saying something along the lines of: "I ran a program that was limited to allocating 800MB of ram in login.conf and my program attempted to allocate 10 GB of ram and my system has 500MB of physical memory and 500MB of swap and the program crashed, but when I changed the program to run under a userID that is unlimited and ran it again, the operating system crashed" Ted Mittelstaedt tedm@toybox.placo.com Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000201c19a7a$94a7d840$1401a8c0>