sah@gumby (Steve Hanson) (09/03/89)
In article <3248@itivax.iti.org>, dhw@itivax (David H. West) writes: >I've seen a few debugging compilers (on mainframes) which just >reserve an infrequently used normal value to mean 'uninitialized', >initialize variables to this, and check for it before each use. >True, you were then out of luck if you *really* wanted -1.3E-38 (real) >or -2^32 (4 byte int) or whatever, but then you were out of luck anyway >if you wanted -1E39 or -2^32 -1. > >There's no reason this trick woudn't work on micros, but there would >be losses in speed, code size and the feasibility of certain hacks. >I think this is acceptable so long as the trick can be disabled. In >fact, I'm surprised that Borland haven't done it. > >-David West dhw@itivax.iti.org The 2.10 MIPS Compiler via an option initializes local memory and malloc'ed memory to NaN's and enables the Invalid Operation Exception in the floating point control/status register. An invalid operation exception is signaled if any arithmetic operation is applied to a signaling NaN. The signal together with the debugger gives the user some idea where things start going bad. Granted this only works for floating point, but nevertheless it's helpful, requires no additional hardware, no compiler checking and applies across languages. This idea was contributed by Meta-Software, Inc. makers of HSPICE, an industrial compute-intensive, circuit simulator written in fortran. --
rhg@cpsolv.UUCP (Richard H. Gumpertz) (09/06/89)
If you are interested in use of error detecting codes for detecting uninitialized variables plus a lot more, you might want to hunt down a copy of my thesis: "Error Detection with Memory Tags", Carnegie-Mellon University, 1981 (CMU Computer Science Tech. Report CMU-CS-84-122). If nothing else, it cites some historical use of parity for detecting both uninitialized variables and type mismatches. Richard H. Gumpertz
glen@sunscreen.UUCP (Glen Ivey) (09/15/89)
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. >(Something like that, for example, is used by chip designers to find >bugs. For example, one of our guys did a program that generated >"random" self-checking floating-point programs. It found quite a >few bugs... Other companies do something similar, I believe.) Yes, it is often useful to use randomly generated data for testing computationally intensive ICs. (Chips that merely push data around, rather than operating on it, such as communications chips and formaters, aren't helped as much because the data path is generally much simpler.) I've recently worked on several algorithmic chips (the Stac 9707 Reed-Solomon ECC chip, and 9703/9704 Data compression chips), and always used this type of test. However, it is useful not because it finds more bugs, but because it does it quicker. During the initial stages of debugging a chip, it is convenient to be able to generate a lot of test vectors quickly, with out spending much time figuring out which specific parts of the design are being exercised. However, long before deciding that a design "works," a series of comprehensive tests, developed with careful study of both the specification and the internal workings of the chip, should be developed and run. 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. A single uninitialized pointer bug which corrupts part of 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. =============================================================================== Glen Ivey {ames,uunet,amdahl}!oliveb!cirrusl!glen Cirrus Logic glen%cirrusl%oliveb@ames.arc.nasa.gov --Not only are my opinions not necessarily my companies, they aren't always mine either. ===============================================================================
mash@mips.COM (John Mashey) (09/15/89)
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: <generic disclaimer, I speak for me only, etc> 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