Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!apple!vsi1!wyse!mips!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.arch Subject: Re: uninitialized variable checking Message-ID: <27570@winchester.mips.COM> Date: 14 Sep 89 22:25:52 GMT References: <854@cirrusl.UUCP> Reply-To: mash@mips.COM (John Mashey) Organization: MIPS Computer Systems, Inc. Lines: 44 In article <854@cirrusl.UUCP> glen@sunscreen (Glen Ivey) writes: >In article <26685@winchester.mips.COM> mash@mips.COM (John Mashey) writes: >>6) One possibility, that actually might of marginal use, is to >>have an OS option that (in UNIX, for example), RANDOMIZED .bss and >>sbrked storage. If you then ran your program several times, >>and it did the same thing, your confidence level would be raised..... > Yes, it is often useful to use randomly generated data for testing >computationally intensive ICs. > There is a similar situation with software. Just because a >program has run correctly a few times with a randomly generated >initial state, DOES NOT mean that it is correct. In fact, it seems >that such randomization would be a hindrance to locating the source of >a bug...... >memory is relatively easy to find, IF it always corrupts the same part >of memory. If there is a random element in the system causing the >uninitialized bug to behave differently with each execution, how can >it be tracked down? How do you know there's only one bug? If the bug >doesn't appear until after the program is shipped, how can the user >write a bug report? > Sorry to get quite so dogmatic about this, but I've seen enough >"finished" products (hardware and software) that broke as soon as they >came near a user that I've gotten a bit paranoid about verification. >In short, I don't really see how hardware/OS modifications that trap >uninitialized variable references would be useful. Yes, there is >always one more bug, but given a rigorous QA program, the likelyhood >that that bug is an uninitialized variable should be very low. Sorry if this was misleading; there was zero intent of making anyone believe that randomization was a substitute for careful QA, rather than just another potential technique for finding some classes of bugs, typically EARLY in the sequence of testing, and mostly because it was easy to do mechanically. [On the chip side, I don't know anyone who uses random tests who does nto also have a carefully-crafted set of other diagnostics.] Note the difference between tracking down a bug when you know you have one, and knowing that you have one. Randomization is for alerting you that something is wrong, by the fact that a program gives different answers for the same input. -- -john mashey DISCLAIMER: UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086