Jump to content

Talk:Heisenbug: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
Apankrat (talk | contribs)
696 edits
Darekun (talk | contribs)
155 edits
→Schroedinbugs: yes on "magical"
Line 40: Line 40:
:::The kind of bug you just described would be considered "magical", and I've never heard of that sort of thing. I have had mysterious errors occur for seemingly no reason, and then discovered that the source code should not have worked at all. To me, this is close enough to any reasonable definition of Schroedinbug. There's no actual possible way for a program to stop working simply because the programmer looks at the code. Any situation where that seems to happen is probably due to the compiler having neglected to recompile the source code for that module promptly, and only recompiling the file when the programmer opens it up to look.
:::The kind of bug you just described would be considered "magical", and I've never heard of that sort of thing. I have had mysterious errors occur for seemingly no reason, and then discovered that the source code should not have worked at all. To me, this is close enough to any reasonable definition of Schroedinbug. There's no actual possible way for a program to stop working simply because the programmer looks at the code. Any situation where that seems to happen is probably due to the compiler having neglected to recompile the source code for that module promptly, and only recompiling the file when the programmer opens it up to look.
:::Another way to look at it is that it's a type of error which is prevented from occuring by sheer dumb luck (accidently zeroed memory when it was unintentionally left randomized at allocation), until circumstances (database records, users connected, bytes allocated etc) change in a way that happens to break it completely. At that point, somebody looks at the code and wonders how in heck it ever worked at all. [[User:Prgrmr@wrk|Prgrmr@wrk]] 18:53, 6 July 2007 (UTC)
:::Another way to look at it is that it's a type of error which is prevented from occuring by sheer dumb luck (accidently zeroed memory when it was unintentionally left randomized at allocation), until circumstances (database records, users connected, bytes allocated etc) change in a way that happens to break it completely. At that point, somebody looks at the code and wonders how in heck it ever worked at all. [[User:Prgrmr@wrk|Prgrmr@wrk]] 18:53, 6 July 2007 (UTC)
::::I'd say that calling a bug a Schroedinbug is also calling it "magical" - and is therefore generally done facetiously. We recently had one here at work(and I reffed the hardware engineers to this page); I suspect it was due to state held by Windows, and that the timing of me reading the code and them rebooting was coincidental... but I couldn't prove it. [[User:Darekun|Darekun]] 00:24, 23 October 2007 (UTC)


I reworded the paragraph on schroedinbugs, to improve sentence flow a bit. I also removed the bit about superstition because it seemed like an assumption to me. Describing a bug using this word is usually done out of frustration or humor, not out of fear or belief in mystical forces. [[User:Prgrmr@wrk|Prgrmr@wrk]] 03:24, 15 July 2007 (UTC)
I reworded the paragraph on schroedinbugs, to improve sentence flow a bit. I also removed the bit about superstition because it seemed like an assumption to me. Describing a bug using this word is usually done out of frustration or humor, not out of fear or belief in mystical forces. [[User:Prgrmr@wrk|Prgrmr@wrk]] 03:24, 15 July 2007 (UTC)

Revision as of 00:24, 23 October 2007

Template:FOLDOC talk

Oppenhimerbugs

Maybe there is also a new type called Oppenhimerbugs. They look harmless at the beginning but after deployment they have catastrofic effects. //mats@henricson.se — Preceding unsigned comment added by 194.237.142.13 (talk • contribs)

Hindenbugs

This edit added a new type: "hindenbug" but it reads like a hoax, or at best case, Original Research. I reverted it, feel free to revert it back, if there is some documented non-facetious usage out there. Segv11 (talk/contribs) 09:09, 27 January 2006 (UTC)[reply]

207.102.59.149 17:49, 7 June 2006 (UTC) Fermat-bugs 207.102.59.149 I added this section. It wasn't original with me but the chap who thought of it is not, to my knowledge, attached to it excessively. I mentioned the four classes of bug (Bohr-bug, Heisen-bug, Schröde-bug and Mandel-bug) to a co-worker (Don Lekei, formerly deskpotato.ca) and he blurted the Fermat bug in a laugh as a follow-on. Arthur N. Klassen ansak.blogspot.com etc...[reply]

Fermat-Bug?

Google doesn't pick anything up on it besides this page. Seems to me like original research. Poorly written original research. --Angry Lawyer 09:49, 19 June 2006 (UTC)[reply]

Removing Alksub 05:04, 21 June 2006 (UTC)[reply]

Anti-Heisenbugs?

Is there a name for bugs that only show up in debug mode while you're trying to fix another bug? Arandomrabbit 05:40, 19 August 2006 (UTC)[reply]

Phase of the moon bugs

I strongly disagree with the statement that Phase of the moon bugs are rare. One from my own experience: I wrote a shell script which used a date in a filename. As I usually sleep in the morning, I didn't notice that before 10am the script generated a blank in the filename, causing the script to fail.

Bohrbug

Some of the statements about bohrbug ("They may never be fixed, but if the operation is retried or the system is rebooted, the bugs may not manifest themselves as failures. Manifestation is dependent on the software reaching very rare states.") in the previous version were inconsistent with the generally definition contained in the jargon file and the Free On-line Dictionary of Computing ("manifests reliably under a possibly unknown but well-defined set of conditions"). I have removed these statements, and I have added parts of the definition from the Free On-line Dictionary of Computing instead.

Schroedinbugs

I think that the example used (the one about the database table size) really does not match the scenario of a schroedinbug. These are of such mystery that such a simple example would not be sufficiently descriptive. - Bevo 16:32, 4 July 2007 (UTC)[reply]

Schroedinbugs don't need to be complicated, they just need to be an error that seems to spontaneously occur. If that error occured during runtime to a user who was unfamiliar with the program, it would certainly seem to be completely random. I agree that the given example is too simple to often fall into this category, but it's an easy to understand example, which is the point. Prgrmr@wrk 18:24, 5 July 2007 (UTC)[reply]
Schroedinbugs occur permanently for all users after a programmer looks at the source code and realizes that the program is flawed. They are so mysterious that I'm wondering if anyone reading this has actually had experience with one. I have not or I'd provide a better example. Is this a real world thing, or just someone's joke? I know someone put it into the infamous Jargon file, but so far, that is the only source for that term I can find. I'd like it to stay in the article, but the example in there is not a schroedinbug. - Bevo 18:44, 5 July 2007 (UTC)[reply]
The kind of bug you just described would be considered "magical", and I've never heard of that sort of thing. I have had mysterious errors occur for seemingly no reason, and then discovered that the source code should not have worked at all. To me, this is close enough to any reasonable definition of Schroedinbug. There's no actual possible way for a program to stop working simply because the programmer looks at the code. Any situation where that seems to happen is probably due to the compiler having neglected to recompile the source code for that module promptly, and only recompiling the file when the programmer opens it up to look.
Another way to look at it is that it's a type of error which is prevented from occuring by sheer dumb luck (accidently zeroed memory when it was unintentionally left randomized at allocation), until circumstances (database records, users connected, bytes allocated etc) change in a way that happens to break it completely. At that point, somebody looks at the code and wonders how in heck it ever worked at all. Prgrmr@wrk 18:53, 6 July 2007 (UTC)[reply]
I'd say that calling a bug a Schroedinbug is also calling it "magical" - and is therefore generally done facetiously. We recently had one here at work(and I reffed the hardware engineers to this page); I suspect it was due to state held by Windows, and that the timing of me reading the code and them rebooting was coincidental... but I couldn't prove it. Darekun 00:24, 23 October 2007 (UTC)[reply]

I reworded the paragraph on schroedinbugs, to improve sentence flow a bit. I also removed the bit about superstition because it seemed like an assumption to me. Describing a bug using this word is usually done out of frustration or humor, not out of fear or belief in mystical forces. Prgrmr@wrk 03:24, 15 July 2007 (UTC)[reply]

Notability

Heisenbug is notable, the rest are not. Here are some stats to back this up -

The same queries, but now excluding Wikipedia -

Given the above, the Mandelbug and Bohrbug sections need to be substantially trimmed down due to the lack of notability. The same goes for Schroedinbug, but due to WP:NOR. All in all, Heisenbug is the original geeky subject, that dates back to 1987. The rest are trivial derivatives of an unclear origin and little notability. As such their extended descriptions do not belong to WP. Alex Pankratov 05:43, 23 August 2007 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=Talk:Heisenbug&oldid=166409305"