Talk:Heisenbug

message: 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)
thread_title:  Hindenbugs 

message: 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)
replies: text: Removing Alksub 05:04, 21 June 2006 (UTC)
thread_title:  Fermat-Bug? 

message: 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)
thread_title:  Anti-Heisenbugs? 

message: 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. UNSIGNED.
: Many JavaScripters use new Date() to generate a Date Object, then set various "parts" of the date/time in turn.  That has an interesting effect if one tries to go from a day at the end of a long month into a short month.  Using setFullYear(Y, M, D) would fix it.  However, if the current actual time is not wanted, it is both safer and faster to use  new Date(0). 82.163.24.100 (talk) 23:16, 22 January 2010 (UTC)
replies: text: A difficult to diagnose 'phase of moon' bug I encountered in the late 1970's: a new release of operating system would only work on our particular computer on even-numbered years, but it worked on supposedly identical models elsewhere.  A colleague examined various operating system traces and after some 3 months determined that there was a missing interrupt/trap.  Using multi-level virtual machine facilities I devised a short assembler program which exhibited the fault.  The engineers then quickly determined that there was a wire missing from the computer backplane.  The relation with the date was simple in retrospect:  the year number happened to be in a register when the instruction to cause the trap was executed, but due to the missing wire, the low order bit (even/odd) of the register controlled whether or not the trap actually occurred. Murray Langton (talk) 12:30, 6 May 2010 (UTC)
thread_title: Phase of the moon bugs

message: 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.
A Bohr Bug isn't really an unusual bug at all.  "If i do this, then this, and then I do this, the program always crashes" is a Bohr Bug.  Most bugs are in fact Bohr Bugs.  Sometimes determining why the specific set of circumstances always causes the bug to manifest is non trivial, though. 99.99.70.93 (talk) 07:14, 4 December 2010 (UTC)
thread_title: Bohrbug

message: Heisenbug is notable, the rest are not. Here are some stats to back this up -
* http://www.google.ca/search?q=Heisenbug - 84000 hits
* http://www.google.ca/search?q=Bohrbug+-music - 1160 hits
* http://www.google.ca/search?q=Mandelbug - 996 hits
* http://www.google.ca/search?q=Schroedinbug - 9800 hits
The same queries, but now excluding Wikipedia -
* http://www.google.ca/search?hl=en&q=Heisenbug+-wikipedia - 71500 hits
* http://www.google.ca/search?q=Bohrbug+-music+-wikipedia - 661 hits
* http://www.google.ca/search?q=Mandelbug+-wikipedia - 895 hits
* http://www.google.ca/search?q=Schroedinbug+-wikipedia - 884 hits
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)
thread_title:  Notability 

message: The paragraph mentioning the Turing test is entirely missing the point; calling a bug a Mandelbug asserts that it could be debugged as a Bohr bug, but that doing so would require excessive effort, for example the FOLDOC mention of seventh-level damage. However, I suspect both arguments are OR, and the paragraph should simply be deleted.
:Oops, forgot to sign that. Darekun 00:34, 23 October 2007 (UTC)
thread_title:  Mandelbugs 

message: I notice that this article seems to be verbatim from the relevant sections of the Jargon Files. Perhaps a rewrite is in order? Dazcha 09:29, 4 December 2007 (UTC)
thread_title:  Copyright? 

message: I've merged Ghosts in the code here. I'm not sure there's any difference between this and Bohrbug. So perhaps the two sections should be merged. Pichpich (talk) 17:28, 15 February 2008 (UTC)
thread_title:  merged from ghost in the code 

message: In Unusual software bug#Heisenbug we find: A heisenbug [...] is a computer bug that disappears or alters its characteristics when an attempt is made to study it.
In Probe effect we find: Probe effect is unintended alteration in system behavior caused by measuring that system.
They seem to be talking about the same phenomenon. Therefore, I propose that the stub article Probe effect be merged into the section Unusual software bug#Heisenbug. --Antonielly (talk) 11:18, 25 February 2009 (UTC)
thread_title:  Merge proposal 

message: #I agree with the merge suggestion. Canadian Monkey (talk) 17:35, 16 December 2008 (UTC)
thread_title: Agree

message: #Oppose - While the concepts are quite similar, I read one article as being about semi-serious jargon, while the other is technical. They don't seem to fit together from the perspective of what would reference them. However, I suggest that "Probe effect" might be submitted for deletion. It has little content and is more like a dictionary entry. It is linked to from only two articles. One is Event monitoring, which is an orphan itself and already includes a definition of "probe effect." The other is DTrace, which needs only half a sentence to define its usage of the term. ChrisMiddleton (talk) 02:23, 25 February 2009 (UTC)
thread_title: Disagree

message: Is there a name for something that is definitely a bug, but fixing the bug causes problems, even when the bug itself did not cause problems ?
Causes can be later developers working around the bug instead of fixing it, or the original developer making two mistakes that cancel out.
Could be OR ...
--87.194.174.252 (talk) 15:26, 11 May 2009 (UTC)
thread_title:  Another species ? 

message: A bug which happens when a certain member of the team is not present and goes away when he/she is observing the reproduction of it. At this point the certain member can conclude the bug happens or fixes itself due to gamma rays stimulating the software differently in relation to the certain team member. It is rather funny, than scientific description.  —Preceding unsigned comment added by 71.172.125.78 (talk) 23:02, 13 February 2010 (UTC)
thread_title:  Gamma Ray bug 

message: I find it rather frustrating that the strfry bug mentioned as an example doesn't really seem to be fixed: http://sourceware.org/bugzilla/show_bug.cgi?id=4403 -opello (talk) 18:35, 6 September 2009 (UTC)
thread_title:  Statistical 

message: Consider adding a new section, possibly titled "Relationships and Inconsistencies Between Mandelbugs, Bohrbugs and Heisenbugs". The content would consist of the last three paragraphs from "Mandelbugs" starting with "In the literature..." and continuing thru "In a recent column in IEEE Computer..."
The information is related to "Mandelbugs", but it is also directly related to Bohrbugs and Heisenbugs so does not belong directly inside any one of these three sections. The new section might appear immediately following the three sections it discusses so it is easy to find and the article's flow continues logically (not sure about style here or if there is an existing rule).  —Preceding unsigned comment added by Derekread (talk • contribs) 00:13, 27 October 2010 (UTC)
thread_title:  Relationships and Inconsistencies Between Mandelbugs, Bohrbugs and Heisenbugs 

message: 1. There is no dictionary word for noob. The official word from the dictionary is newbie. Noob is SLANG.
2. Secondly the examples presented are not actual bugs from the application's code perspective but from the developer's perspective who is inexperienced with his own tools. --Ltsampros2 (talk) 16:32, 12 February 2011 (UTC)
replies: text: There are perfectly adequate words in the English language to describe the concept, without having to resort to slang and baby-talk:  novice, neophyte, newcomer, amateur, etc., etc. —QuicksilverT @ 23:02, 24 February 2011 (UTC)

text: It doesn't matter what words you think constitute proper English and which do not. The only thing that matters is what the Reliable Sources report.--RaptorHunter (talk) 16:55, 11 May 2011 (UTC)
thread_title:  Noob bugs? 

message: OK, I think we all agree this article has issues:
# "Heisenbug" is probably a legitimate topic; it's jargon but it's a term that people actually use and that actually appears in the literature. "Bohrbug" also appears in the literature, but mostly in discussions of "Heisenbug" and even then only in jest: "...and if these here wacky bugs are called 'Heisenbugs', then these here regular bugs should probably be called 'Bohrbugs' or something, ha ha." "Mandelbug" and "Schrödinbug" have zero currency; they appear almost exclusively where people either mirror or directly quote from the pertinent pages from Wikipedia or the Raymond version of the Jargon File. 
# The text under "Statistical bug" and "Alpha particle bug" describes legitimate phenonama, but 
##I have my doubts that "statistical bug" and "Alpha particle bug" are common expressions frequently used in this sense by actual authors,
##they clearly don't belong into an article about a snarky jargon term. 
#In the same vein, "unusual software bug" is almost certainly not a useful headword.
If there are no strong objections, I will, one week from now,
# merge "Phase of the Moon bug", "Statistical bug", and "Alpha particle bug" into the articles they belong,
# convert the rest of the article into an article on "Heisenbugs", condensing "Bohrbug", "Mandelbug", and "Schrödinbug" to the footnotes they naturally are.
:Noym (talk) 17:17, 20 September 2011 (UTC)
thread_title:  Cleanup 

message: Why unusual? Perhaps "Humorous software bug classification" would be better? Then again, it seems to me that the whole concept could be better handled by removing everything but "Heisenbug" and moving that description to, say, a section in software bug. 130.235.35.101 (talk) 06:30, 17 October 2011 (UTC)
thread_title:  Why "unusual"? 

message: From all the comments above it seems pretty clear that "Heisenbug" is the only term which has sufficient use to deserve an entry; the rest are second-order jokes with hardly any mention outside the Jargon File, and hardly deserve a mention.  Thus I second the proposal to trim those sections, and furthermore propose to rename the page "Heisenbug".--Jorge Stolfi (talk) 16:00, 25 December 2011 (UTC)
thread_title:  Cleanup and renaming proposal 

message: The section that explains how a bug can appear "when the program is compiled with an optimizing compiler, but not when the same program is compiled without optimization" ends with a clear statement that this is (always) the optimizing compiler's fault. I disagree, and expanding on the FP precision topic outlined in this section, i would consider such a program (that fails to account for minor changes in precision) to be buggy; it doesn't matter if the decision to use registers is done by the compiler (statically), or (dynamically, at run-time) by the Framework, or the Operating System. -- Jokes Free4Me (talk) 12:04, 7 February 2012 (UTC)
replies: text: Heisenbugs manifesting in programs compiled with an optimizing compiler might result from programmer's reliance on undefined behavior. Assumptions made about non-compliant code can be invalidated by the compiler trying to optimize the code in accordance with specification. Striepan (talk) 10:38, 27 March 2014 (UTC)
thread_title:  bug in the optimizing compiler and not in the program 

message: http://books.google.ca/books?id=hGAEAAAAMBAJ&pg=PA22
This link is cited under 'Related terms': A mandelbug (named after Benoît Mandelbrot's fractal) is a bug whose causes are so complex it defies repair, or makes its behavior appear chaotic or even non-deterministic.[9]
A schrödinbug (named after Erwin Schrödinger and his thought experiment) is a bug that manifests itself in running software after a programmer notices that the code should never have worked in the first place.[9]
Despite being published in an obviously reputable magazine, this article cites Wikipedia as its own source! Not sure what the protocol is for dealing with this.  — Preceding unsigned comment added by 92.232.153.218 (talk) 13:33, 17 February 2012 (UTC)
thread_title:  Wikipedia citing itself? 

message: The only example given in the article for a Heisenbug is of an elusive bug in "OpenOffice". That bug was actually a bug in CUPS and was listed earlier as an OpenOffice bug because this is the software the user was using. However I'm not sure this is a good example of a Heisenbug as per the definition in this article. The bug in question was very much deterministic. It turned out that it was easy to reproduce. It would happen under certain conditions: the printed job needed to be of a certain (but common) type, and the day of the week (according to the system clock) needed to be Tuesday. Tzafrir (talk) 06:41, 9 September 2013 (UTC)
replies: text: But it wasn't easy to reproduce. If the person trying to reproduce the bug were to try on the wrong day, they could easily write it off. It's a good example since the conditions were not clear at the outset but once it is understood what the conditions are, it's easy to see it as a valid bug. Walter Görlitz (talk) 06:46, 9 September 2013 (UTC)
thread_title:  The "OpenOffice" HeisenBug 

message: Circa 1990, I wrote Unix Korn shell script that was essentially one big loop. It died somewhere in the middle of the loop, so I put in a line that spat out the values of some of the variables so I could see just where it died. This time, it ran fine. So I took out the debugging code, and it died somewhere in the loop.
So I put the debugging line back in, redirected the output to the Null device, and inserted a comment:
# The next line is here because, if you take it out, the program will not run
I suspect it was a timing issue, but I had neither the time nor the inclination to find out. JHobson3 (talk) 09:38, 16 September 2014 (UTC)
thread_title:  An example of a Heisenbug 

message: "A mandelbug (named after Benoît Mandelbrot's fractal) is a bug whose causes are so complex...."
This seems to have been copied straight from JF or FOLDOC, but in any case it puzzles me.  The formula that generates the Mandelbrot set is very simple.  On this basis, I would expect a mandelbug to be a small mistake, such as a one-character typo, that causes the program to go haywire.
That said, I've just searched and found one source that defines "Mandel Bug" similarly to what I've just said.  Trouble is this is the only source I've found so far.  In any case, it would be nice if we can find and link to some insight into the origin of the definition that is given here.... — Smjg (talk) 17:51, 27 November 2014 (UTC)
thread_title:  Why is mandelbug so defined? 

message: To User:Walter Görlitz:  I didn't notice the introductory boldfacing; hence my mistake that you reverted.  Now I added a forward reference in the intro, where "Similar terms" are listed, to the section where they are defined.  Why?  Because the redirects from those terms (those I checked, at least) don't indicate that they are actually defined lower down in this article.  The naive redirected reader may (like me) not realize they are defined after the intro where they are boldfaced.  If you disagree, this should be discussed.  Zaslav (talk) 06:58, 2 September 2017 (UTC)
thread_title:  Similar/related terms 

message: This article repeats a common error in understanding Heisenberg's uncertainty principle. Heisenberg's uncertainty principle is NOT an observer effect. The uncertainty arises due to the properties of waves and is completely separate from an observer perturbing the system they're trying to measure. This is even mentioned in the linked article on the 'observer effect'.  — Preceding unsigned comment added by 198.129.106.58 (talk) 21:48, 6 September 2017 (UTC)
thread_title:  'Observer effect' 

message: Hello fellow Wikipedians,
I have just modified 2 external links on Heisenbug. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20141230005029/http://debuggers.co/java/enterprise/2014/06/17/Kyle-Harr.html to http://debuggers.co/java/enterprise/2014/06/17/Kyle-Harr.html
*Added archive https://web.archive.org/web/20101216173357/http://ftp.sunet.se/jargon/html/magic-story.html to http://ftp.sunet.se/jargon/html/magic-story.html
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 11:21, 1 November 2017 (UTC)
thread_title:  External links modified 

message: In short, this section doesn't make sense (any more?). It may have been edited with good intentions at some point, or perhaps it never made sense.
Either way, to have as its first words "The term was also used..." (my emphasis) is pretty broken and suggests that maybe those words were originally part of the second or later sentence in the section. Moreover the rest of the section never says anything about who coined the term, or when it happened. Even the linked article about Bruce Lindsay's interview fails to give a date, or name the other participants (and it seems clear that Bruce didn't coin the term himself).
If those familiar with the article can adjust it, that would be great. If not, I may try and dig back through the history of the text in an effort to unpick what went wrong.
For the record, the full text (without line breaks) of the section as it currently stands is: "The term was also used in 1985 by Jim Gray, in a paper about software failures[17] (and is sometimes mistakenly attributed to him because of this publication) and also in 1986 by Jonathan Clark and Zhahai Stewart on the mailing list (later Usenet news group) comp.risks.[18] Bruce Lindsay, a researcher at IBM, affirmed in a 2004 ACM Queue interview that he was present when the Heisenbug was originally defined.[19] An earlier appearance in ACM publications is from 1983.[20]"
Smudgeface (talk) 14:10, 12 June 2022 (UTC)
replies: text: With respect to the term 'also', it was introduced in this edit, the first sentence of which was later removed because it lacked sources. I've removed it. Mindmatrix 16:15, 12 June 2022 (UTC)
thread_title:  Etymology text is broken... 

message: User:Woutput has queried the statement: "This may affect, for instance, the result of floating-point comparisons, since the value in memory may have smaller range and accuracy than the value in the register"
I have personal experience of this happening:  Consider the test:   if 1/3 = 1/3 then ...
On the Elliott/ICL 4130 computer, a simple implementation resulted in the above test being  false.
Floating point values occupied 48 bits in memory (39-bit mantissa, 9-bit exponent), but the floating point accumulator had a 48-bit mantissa.  So calculate the first '1/3' and store it in memory with a 39-bit mantissa. Then calculate the second '1/3' in the floating point accumulator with a 48-bit mantissa, with the last 9 bits being non-zero.  Compare accumulator with the value in memory, and they don't match!
The only way to get 'true' was to store both values in memory with rounding to a 39-bit mantissa, then reload one of them into the floating point accumulator and compare with the other value in memory.
Murray Langton (talk) 17:19, 9 March 2024 (UTC)
thread_title:  Floating point comparison