div. zero bugs?
Locked
 
|
What do you guys call the class of programming errors that act like
viruses in multiplying the complexity of a program's calculations to the point of overwhelming the machine, logical flaws that have the effect of dividing by zero. Do you have a name for them, or just swear a lot? Is there any theory for fixing them other than 'just don't do that'? Are there self-protecting sentinel circuits or routines to catch them in the act and shut them down? Any references? Phil Henshaw ????.?? ? `?.???? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 680 Ft. Washington Ave NY NY 10040 tel: 212-795-4844 e-mail: pfh at synapse9.com explorations: www.synapse9.com <http://www.synapse9.com/> -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/friam_redfish.com/attachments/20061024/70f39f6c/attachment.html |
|
|
phil henshaw wrote:
> What do you guys call the class of programming errors that act like > viruses in multiplying the complexity of a program's calculations to > the point of overwhelming the machine, logical flaws that have the > effect of dividing by zero. One class of exceptions I'd call "passing the buck". "I don't know what to do so I'll go through some obligatory motions and give this to the caller" (Inserting some junk code to show they thought about the possibility for a few seconds.) Sooner or later a user of the library code and punts and ignores the whole thing and then some potentially weird failure occurs a bit later. In C, for example, this idiom: if ((ptr = malloc (100)) == NULL) return -1; [A memory allocation failure is pretty much always fatal anyway -- they might as well just abort so the failure is localized when someone looks at it in a debugger. Instead of it sneaking away by a few layers of indirection.] In Common Lisp, and to some extent in Java, there is an orthogonal technique for dealing with exceptions. Any code that can fail can signal a hierarchy of exception types, and then user can (or must) trap them with separate code. Common Lisp fully separates signaling, handling, and recovery in a nice object-oriented way: http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html |
|
|
In reply to this post by phil henshaw
phil henshaw wrote:
> Are there self-protecting sentinel circuits or routines to catch them > in the act and shut them down? A couple examples come to mind: 1) floating point hardware knows when calculations have gone bad due to underflow, overflow, divide by zero, etc. The operating system kernel can notice these and signal them as exceptions, if the user prefers. The sanity checks are in hardware as are the task switching / recovery mechanisms for inspecting them. 2) The memory management unit of computer knows about the mapping from physical addresses to virtual ones and knows the difference between valid and invalid memory addresses. Addresses can be handed out and reclaimed such that bad addresses due to programming mistakes cause hardware traps (e.g. the Electric fence malloc library). A crude form of this is for Unix users is the segfault or a bus error signals. |
|
|
Marcus,
> > phil henshaw wrote: > > Are there self-protecting sentinel circuits or routines to > catch them > > in the act and shut them down? > A couple examples come to mind: > > 1) floating point hardware knows when calculations have gone > bad due to > underflow, overflow, divide by zero, etc. The operating > system kernel > can notice these and signal them as exceptions, if the user prefers. > The sanity checks are in hardware as are the task switching / > recovery mechanisms for inspecting them. Not sure I understand. What's an 'exception'. Is it related to what I was asking about, the chain of conditions getting trapped in increasing complexity, or does it mostly refer to just non-existent address faults and things like that? You say 'sanity checks' are hardware based. Is 'insanity' just anything that doesn't work, or is it more specific in the kinds of things that are the persistent dangers of faulty programming? Do any of the kinds of common exceptions have developmental process curves? You mentioned a "hierarchy of exception types" in your last post. Would that include some that take off right away and some that sputter and then blow up to fry the chip, and things like that? If there are torrents of signals that push the physical limits of the hardware I think they'd have locally unique emergent properties if you looked at them closely with that in mind. > > 2) The memory management unit of computer knows about the > mapping from > physical addresses to virtual ones and knows the difference between > valid and invalid memory addresses. Addresses can be handed out and > reclaimed such that bad addresses due to programming mistakes cause > hardware traps (e.g. the Electric fence malloc library). A > crude form > of this is for Unix users is the segfault or a bus error signals. > > ============================================================ > FRIAM Applied Complexity Group listserv > Meets Fridays 9a-11:30 at cafe at St. John's College > lectures, archives, unsubscribe, maps at http://www.friam.org > > |
|
|
Phil writes: > Not sure I understand. What's an 'exception'. Is it > related to what I > was asking about, the chain of conditions getting trapped in > increasing complexity, or does it mostly refer to just > non-existent address faults > and things like that? Here's some wikipedia entries that may help translate the software vernacular to your space. http://en.wikipedia.org/wiki/Exception_handling http://en.wikipedia.org/wiki/Sanity_check http://en.wikipedia.org/wiki/Software_testing |
|
|
In reply to this post by Phil Henshaw-2
Phil Henshaw wrote:
> Is it related to what I > was asking about, the chain of conditions getting trapped in increasing > complexity, or does it mostly refer to just non-existent address faults > and things like that? > Some relatively ordinary software can do that. A generational garbage collector, as in a Java virtual machine, if it is not implemented just right can crash far away from the bug in the implementation. Imagine if all of the objects in a room are swirling around out from you and you must depend on a slightly misinformed and color blind assistant to find what you need in a short window of time. That assistant, if he helpfully but smugly nails down an object, the room might catch on fire or he might become one of the objects swirling around. It sounds like you are interested in something else, a sort of Tower of Babel where computer software goes mad by trying to correct the uncorrectable. Overall, I think, most software just crashes and has no real mechanism for self-correction that might drive it into an escalating cycle of self-reflection and ineffectual adaptation. Machine learning codes or agent models certainly could... > Is 'insanity' just > anything that doesn't work, or is it more specific in the kinds of > things that are the persistent dangers of faulty programming? Once a iterative floating point calculation has gone into to a very large or very small range, it's useful to have the system alert the user so that it doesn't continue and create nonsense results. In principle a calculation could be adaptive on these signals, but typically it's just something to be understood and then avoided. > Do any of the kinds of common exceptions have developmental process curves? > Indifference to memory use is probably a general downward spiral in software today as we have $500 computers with a billion places to put something without even hitting disk. It's possible to have gross leaks in a program (or gross overallocation in a garbage collected system), and not notice them. Under different system loads such programs will behave very differently (as memory access speeds goes down and down). > You mentioned a "hierarchy of exception types" in your last post. Would > that include some that take off right away and some that sputter and > then blow up to fry the chip, and things like that? If there are > torrents of signals that push the physical limits of the hardware I > think they'd have locally unique emergent properties if you looked at > them closely with that in mind. > A modern CPU has multiple execution units that are all looking for work to do from a program. Most programs will fail to keep all of that circuitry running, but occasionally a special code will really get the whole engine pumping. A system without top notch cooling (but one built to to spec.) can then have CPUs miscalculating things or wedging up. Since it can be hard to reproduce, testing of the system by the manufacturer may not turn the problem up. For example when the national labs buy or lease big systems they have long burn-in periods testing all kinds of scientific codes to look for non-determinism and unexplained crashes. Not only to get the hardware all working right, but also to avoid expensive scientific mistakes. |
|
|
About the only useful discovery I've made along these lines:
Never do this: if @var == "Value" Always do this: if "Value" == @var the reason is because, if you screw up and only put in one equals sign, pretty much every language out there is prone to accidental assignment-during-test bugs, but no languages that I'm aware of are prone to accidental assigning-new-values-to-literals bugs. For what it's worth... -- Giles Bowkett http://www.gilesgoatboy.org |
|
|
Giles,
Can you explain what that causes? You say "is prone to accidental assignment". Sounds like variables erroneously change value when queried. That's not good. My limited experience is different, that code has all kinds of unexpected and hidden structure because it was written by people like me who can't keep a few dozen simple logical steps straight when interacting with few dozen others written by someone else (i.e. there's confusion lying all around). Is that also why variables are accidentally reassigned? Or something different? Ok, so then what happens after that? You don't just come to the wrong answers it seems, but frequently trigger a cascade of mismatching stuff that sometimes gets 'trapped' and sometimes not? Would you describe it differently? > > About the only useful discovery I've made along these lines: > > Never do this: > > if @var == "Value" > > Always do this: > > if "Value" == @var > > the reason is because, if you screw up and only put in one > equals sign, pretty much every language out there is prone to > accidental assignment-during-test bugs, but no languages that > I'm aware of are prone to accidental > assigning-new-values-to-literals bugs. > > For what it's worth... > > -- > Giles Bowkett > http://www.gilesgoatboy.org > > ============================================================ > FRIAM Applied Complexity Group listserv > Meets Fridays 9a-11:30 at cafe at St. John's College > lectures, archives, unsubscribe, maps at http://www.friam.org > > |
|
|
He means typing a single = when you meant to type ==.
In mathematics, a single equals means comparison. The concept of assignment is derived from that, through something like "the value of x for which the boolean expression x = <my expression> is true." In C and languages derived from it, = means assignment and == is comparison. However, it's easy to fall back in the old habits that we learned over many years of high school and university, and say something like: if (a = 5) ... when you meant to say if (a == 5) ... Most compiler will warn when you do this, so if you try to ensure your code has zero warnings, you'll notice when it warns you about the mistake. However, if you always put the constant on the left, then when you leave out the other equals, you get this: if (5 = y) which won't compile. I once saw someone's signature file that contained: // World's last bug if (red_button_pressed = 1) launch_missile(); Best, Martin Phil Henshaw wrote: > Giles, > > Can you explain what that causes? You say "is prone to accidental > assignment". Sounds like variables erroneously change value when > queried. That's not good. My limited experience is different, that > code has all kinds of unexpected and hidden structure because it was > written by people like me who can't keep a few dozen simple logical > steps straight when interacting with few dozen others written by someone > else (i.e. there's confusion lying all around). Is that also why > variables are accidentally reassigned? Or something different? > > Ok, so then what happens after that? You don't just come to the wrong > answers it seems, but frequently trigger a cascade of mismatching stuff > that sometimes gets 'trapped' and sometimes not? Would you describe it > differently? > >> About the only useful discovery I've made along these lines: >> >> Never do this: >> >> if @var == "Value" >> >> Always do this: >> >> if "Value" == @var >> >> the reason is because, if you screw up and only put in one >> equals sign, pretty much every language out there is prone to >> accidental assignment-during-test bugs, but no languages that >> I'm aware of are prone to accidental >> assigning-new-values-to-literals bugs. >> >> For what it's worth... >> >> -- >> Giles Bowkett >> http://www.gilesgoatboy.org >> >> ============================================================ >> FRIAM Applied Complexity Group listserv >> Meets Fridays 9a-11:30 at cafe at St. John's College >> lectures, archives, unsubscribe, maps at http://www.friam.org >> >> > > > > ============================================================ > FRIAM Applied Complexity Group listserv > Meets Fridays 9a-11:30 at cafe at St. John's College > lectures, archives, unsubscribe, maps at http://www.friam.org |
|
|
In reply to this post by Phil Henshaw-2
Ooo. This is one that I can answer.
In most computer language syntax, the statement @X = "Y" assigns the value "Y" to variable @X. In some comptuer languages, the *expression* ( @X == "Y" ) compares @X and "Y" for equality (does @X contain the value Y" ?) and returns a result of true or false. In some of those comptuer languages, the assignment statemet @X = "Y" is also considered an expression, in that it returns the value of @X after the assignment. This is often a useful feature. In some of those languages, a non-zero result is considered the same as boolean TRUE E.g. IF ( 1 ) THEN PRINT "IT'S TRUE!" always prints "IT'S TRUE!" because (1) evaluates to TRUE in that context. So, in that kind of language, the typographicial error of omitting one = from a comparison turns the comparison into an assignment, unexpectedly having the side effect of changing the value of the left-side operand! So: // compare for equality, if the result is true, print "EQUAL" IF ( @X == "Y" ) THEN PRINT "EQUAL" Mistype that to leave out one = symbol: // assign value to x, then if x is non-zero/ non-empty, print "EQUAL" IF (X = "Y" ) THEN PRINT "EQUAL" Whoops! Unexpected results! X is always non-empty, because it is assigned the value "Y"! Also, after this statement, X always contains "Y" Giles suggestion, to reverse the order of the terms, is a good one, because it prevents a typo from compiling without error and accidentally causing an assignment at run-time, and instead generates a compile-time error, pointing out the typo! ~~James _____________________ http://www.turtlezero.com On 10/25/06, Phil Henshaw <sy at synapse9.com> wrote: > Giles, > > Can you explain what that causes? You say "is prone to accidental > assignment". Sounds like variables erroneously change value when > queried. That's not good. My limited experience is different, that > code has all kinds of unexpected and hidden structure because it was > written by people like me who can't keep a few dozen simple logical > steps straight when interacting with few dozen others written by someone > else (i.e. there's confusion lying all around). Is that also why > variables are accidentally reassigned? Or something different? > > Ok, so then what happens after that? You don't just come to the wrong > answers it seems, but frequently trigger a cascade of mismatching stuff > that sometimes gets 'trapped' and sometimes not? Would you describe it > differently? > > > > > About the only useful discovery I've made along these lines: > > > > Never do this: > > > > if @var == "Value" > > > > Always do this: > > > > if "Value" == @var > > > > the reason is because, if you screw up and only put in one > > equals sign, pretty much every language out there is prone to > > accidental assignment-during-test bugs, but no languages that > > I'm aware of are prone to accidental > > assigning-new-values-to-literals bugs. > > > > For what it's worth... > > > > -- > > Giles Bowkett > > http://www.gilesgoatboy.org |
|
|
> Giles suggestion, to reverse the order of the terms, is a good one,
> because it prevents a typo from compiling without error and > accidentally causing an assignment at run-time, and instead generates > a compile-time error, pointing out the typo! yeah that's exactly it. these bugs happen a lot. often enough for these jokes: > // World's last bug > if (red_button_pressed = 1) > launch_missile(); I thought that was pretty funny ^_^ -- Giles Bowkett http://www.gilesgoatboy.org |
|
Administrator
|
>> // World's last bug
>> if (red_button_pressed = 1) >> launch_missile(); > > I thought that was pretty funny ^_^ .. for all 7 of us who understood it! -- Owen Owen Densmore http://backspaces.net |
|
|
I was about to say: can someone translate this joke into English? (It
looks funny, but...) ----- Original Message ----- From: "Owen Densmore" <[hidden email]> To: "The Friday Morning Applied Complexity Coffee Group" <friam at redfish.com> Sent: Wednesday, October 25, 2006 8:11 PM Subject: Re: [FRIAM] div. zero bugs? >>> // World's last bug >>> if (red_button_pressed = 1) >>> launch_missile(); >> >> I thought that was pretty funny ^_^ > > .. for all 7 of us who understood it! > > -- Owen > > Owen Densmore http://backspaces.net > > > > > ============================================================ > FRIAM Applied Complexity Group listserv > Meets Fridays 9a-11:30 at cafe at St. John's College > lectures, archives, unsubscribe, maps at http://www.friam.org > > |
|
|
Easy.
Correct version: // World's last bug if (red_button_pressed == 1) launch_missile(); The other version is guaranteed to bomb... -- Doug Roberts, RTI International droberts at rti.org doug at parrot-farm.net 505-455-7333 - Office 505-670-8195 - Cell On 10/25/06, David Breecker <David at breeckerassociates.com> wrote: > > I was about to say: can someone translate this joke into English? (It > looks funny, but...) > > ----- Original Message ----- > From: "Owen Densmore" <owen at backspaces.net> > To: "The Friday Morning Applied Complexity Coffee Group" < > friam at redfish.com> > Sent: Wednesday, October 25, 2006 8:11 PM > Subject: Re: [FRIAM] div. zero bugs? > > > >>> // World's last bug > >>> if (red_button_pressed = 1) > >>> launch_missile(); > >> > >> I thought that was pretty funny ^_^ > > > > .. for all 7 of us who understood it! > > > > -- Owen > > > > Owen Densmore http://backspaces.net > > > > > > > > > > ============================================================ > > FRIAM Applied Complexity Group listserv > > Meets Fridays 9a-11:30 at cafe at St. John's College > > lectures, archives, unsubscribe, maps at http://www.friam.org > > > > > > > ============================================================ > FRIAM Applied Complexity Group listserv > Meets Fridays 9a-11:30 at cafe at St. John's College > lectures, archives, unsubscribe, maps at http://www.friam.org > An HTML attachment was scrubbed... URL: /pipermail/friam_redfish.com/attachments/20061025/f7f6f366/attachment.html |
|
Administrator
|
In reply to this post by David Breecker
In some languages, the assignment operator, "=", not only assigns a
value to a variable, it also returns that value as the expression's value itself. This is to allow things like a=b=c=42; So in the expression red_button_pressed = 1 The value 1 is assigned to the variable red_button_pressed, and returns a "1" as the value for the expression. Unfortunately, this is also interpreted as "true" for conditional statements like "if" and "while" etc. The real intent of the code is to use the == operator, which returns true if the two operands are the same. So the *extremely* common bug of using = rather than == causes entirely unexpected consequences .. launching a missile. // World's last bug if (red_button_pressed = 1) launch_missile(); The solution many programmers got into the habit of is to reverse the variable and the value to be: if (1 = red_button_pressed) launch_missile(); This causes an error within the compiler because "1" is a literal and cannot be assigned to. -- Owen Owen Densmore http://backspaces.net On Oct 25, 2006, at 9:44 PM, David Breecker wrote: > I was about to say: can someone translate this joke into English? > (It > looks funny, but...) > > ----- Original Message ----- > From: "Owen Densmore" <owen at backspaces.net> > To: "The Friday Morning Applied Complexity Coffee Group" > <friam at redfish.com> > Sent: Wednesday, October 25, 2006 8:11 PM > Subject: Re: [FRIAM] div. zero bugs? > > >>>> // World's last bug >>>> if (red_button_pressed = 1) >>>> launch_missile(); >>> >>> I thought that was pretty funny ^_^ >> >> .. for all 7 of us who understood it! >> >> -- Owen >> >> Owen Densmore http://backspaces.net >> >> >> >> >> ============================================================ >> FRIAM Applied Complexity Group listserv >> Meets Fridays 9a-11:30 at cafe at St. John's College >> lectures, archives, unsubscribe, maps at http://www.friam.org >> >> > > > ============================================================ > FRIAM Applied Complexity Group listserv > Meets Fridays 9a-11:30 at cafe at St. John's College > lectures, archives, unsubscribe, maps at http://www.friam.org |
|
|
Owen Densmore wrote:
> So the *extremely* common bug > of using = rather than == causes entirely unexpected consequences .. > launching a missile. > I expect to see both in many circumstances. For example, when opening a file to read that is absent or to write, and write permission is forbidden. if ((fp = fopen (filename, "r")) == NULL) abort (); I haven't really created many bugs because of "=" vs. "==". GCC even gives a warning... $ cat t.c #include <stdio.h> #include <stdlib.h> static void launch_missle () { printf ("Missle launched\n"); } int main (int argc, const char **argv) { int red_button_pressed = 0; if (argc > 1) red_button_pressed = atoi (argv[1]); if (red_button_pressed = 1) launch_missle (); return 0; } $ gcc -Wall t.c t.c: In function ?main?: t.c:18: warning: suggest parentheses around assignment used as truth value |
|
|
In reply to this post by Owen Densmore
> >> // World's last bug > >> if (red_button_pressed = 1) > >> launch_missile(); > > > > I thought that was pretty funny ^_^ > > .. for all 7 of us who understood it! > > -- Owen The odd thing is it made me laugh a lot, as if I understood the joke, even though I have no idea what it means! (except for the idea of leaving the fate of mankind to something that crashes a lot!) Phil > > > > ============================================================ > FRIAM Applied Complexity Group listserv > Meets Fridays 9a-11:30 at cafe at St. John's College > lectures, archives, unsubscribe, maps at http://www.friam.org > > |
|
|
In reply to this post by Douglas Roberts-2
OK, thanks Doug and Owen, I'm laughing.
And I'm also noting that Cormac McCarthy (who has been hanging out at SFI lately, and even thanked the Institute in his last book) has a new one about a post-nuclear-apocalyptic society ("The Road"). Could this be the result of programming error? Or haning out with programmers? ;-) db ----- Original Message ----- From: Douglas Roberts To: The Friday Morning Applied Complexity Coffee Group Sent: Wednesday, October 25, 2006 9:48 PM Subject: Re: [FRIAM] div. zero bugs? Easy. Correct version: // World's last bug if (red_button_pressed == 1) launch_missile(); The other version is guaranteed to bomb... -- Doug Roberts, RTI International droberts at rti.org doug at parrot-farm.net 505-455-7333 - Office 505-670-8195 - Cell On 10/25/06, David Breecker <David at breeckerassociates.com> wrote: I was about to say: can someone translate this joke into English? (It looks funny, but...) ----- Original Message ----- From: "Owen Densmore" <owen at backspaces.net > To: "The Friday Morning Applied Complexity Coffee Group" <friam at redfish.com> Sent: Wednesday, October 25, 2006 8:11 PM Subject: Re: [FRIAM] div. zero bugs? >>> // World's last bug >>> if (red_button_pressed = 1) >>> launch_missile(); >> >> I thought that was pretty funny ^_^ > > .. for all 7 of us who understood it! > > -- Owen > > Owen Densmore http://backspaces.net > > > > > ============================================================ > FRIAM Applied Complexity Group listserv > Meets Fridays 9a-11:30 at cafe at St. John's College > lectures, archives, unsubscribe, maps at http://www.friam.org > > ============================================================ FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org ------------------------------------------------------------------------------ ============================================================ FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/friam_redfish.com/attachments/20061025/02fb6dcb/attachment.html |
|
|
More coding fun; this from the footer on slashdot.org today:
if (argc > 1 && strcmp(argv[1], "-advice") == 0){ printf("Don't Panic!\n"); exit(42); } (Arnold Robbins in the Linux Journal of February '95, describing RCS, the Revision Control System) Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/friam_redfish.com/attachments/20061026/1b744070/attachment.html |
«
Return to Friam
|
1 view|%1 views
| Free forum by Nabble | Edit this page |