Cutest bug you have ever seen?

Yes, that's a not so easy to spot thing. Hard enough to allow for trailing , these days. :)

If you had only knew how many hours I spent looking for this problem :) - I wasn't so lucky as to get an access violation.

That's a classic example of false assumptions (the assumption being that the code where the error is would be not contain an error).

I think the brain initially skips that part of the code because it just sees what it was expecting to see.

Quote:

---

Originally Posted by Zaccheus

That's a classic example of false assumptions (that the code with the error would be ok).

---

Interestingly, if it were an array of std::string instead, it would really be "okay" in that an access violation would never happen, but the last element would mysteriously be an empty string.

My cutest bug:

http://www.codeguru.com/forum/showthread.php?t=439800

Quote:

---

Originally Posted by laserlight

Interestingly, if it were an array of std::string instead, it would really be "okay" in that an access violation would never happen, but the last element would mysteriously be an empty string.

---

I didn't mean ok in the sense of "the bug not being a problem" but in the sense that I assumed the array was correctly defined.

Quote:

---

#define x 9;

int main()
{
int i = 0;
while (i++ < x)
cout << i << endl;
return 0;
}

---

Preprocessor cannot checked by compiler. I guess why compiler flag an error.

Quote:

---

Originally Posted by Hobson

One more it took me LONG time to find the error:

Code:

---

#include <iostream>
#include <string>
#include <vector>
#include <numeric>
#include <algorithm>

using namespace std;

int main()
{
        vector<unsigned long long> vec;
        vec.push_back(123456789012);
        vec.push_back(987654321098);

        unsigned long long result = accumulate(vec.begin(), vec.end(), 0);
        cout << result;
}

---

I was getting incorrect results although it was guaranted there should be no overflow for unsigned long long type. Still, result was incorrect. Find an error and get a rep point from me :) (And no, you won't get it, TheCPUWizard. Let beginners have some fun :) )

Cheers

---

You're bringing back memories! I (a student) along with a team mentor (a senior programmer at Computer Sciences Corporation (CSC)) once spent several hours debugging a missing "L" on the end of a # define. This was on a 16-bit embedded system, where "unsigned int" rolled over after 65535. No debugger was available - we had only printf() to work with. It wasn't fun.

Quote:

---

Originally Posted by (V|G)CC4ME

You're bringing back memories! <snip> This was on a 16-bit embedded system <snip> No debugger was available - we had only printf() to work with. It wasn't fun.

---

I do not know of a single (commercial) 16 bit processor for which there is not a complete ICE solution with full debuffing capabilities available.

Granted, you may not have had access to one,but......

ps: I have been doing embedded systems development since the mid-1970's.

Quote:

---

Originally Posted by TheCPUWizard

I do not know of a single (commercial) 16 bit processor for which there is not a complete ICE solution with full debuffing capabilities available.

Granted, you may not have had access to one,but......

ps: I have been doing embedded systems development since the mid-1970's.

---

Remember that I'm just talking about hobby/educational stuff. We were actually using this thing:

http://www.ifirobotics.com/rc.shtml

It uses the (8-bit, actually) PIC18F8722, but this proprietary implementation does not allow access to the debugging interface.

Quote:

---

Originally Posted by (V|G)CC4ME

Remember that I'm just talking about hobby/educational stuff. We were actually using this thing:

http://www.ifirobotics.com/rc.shtml

It uses the (8-bit, actually) PIC18F8722, but this proprietary implementation does not allow access to the debugging interface.

---

I used that!!!!!

While somewhat limited the DDT (available from the vendor) is quite useful.

Also the PCM18XS2 will work as a full in-curcuit debugger allowing full capabilities.

Quote:

---

Originally Posted by TheCPUWizard

I used that!!!!!

While somewhat limited the DDT (available from the vendor) is quite useful.

Also the PCM18XS2 will work as a full in-curcuit debugger allowing full capabilities.

---

Ugh. We took one look at the DDT (with its five whole pages of documentation) and decided it wasn't worthwhile.

We did eventually get the MPLAB SIM working, which was very helpful thereafter.

None of it matters anymore, however. Next year, we get to play with the National Instruments cRIO running under WindRiver vxWorks.

Anyway, to maybe get back on topic, here's another story. This one isn't a cute bug but rather a cute programming technique in general.

About five years ago, I decided to teach myself how to program by writing a scientific calculator in VB.NET. The problem is, I didn't know how to program. A few key points:

-I didn't know how to make an array, much less a stack, so I just created twelve global variables and push() and pop() subroutines, which looked like this:

Code:

---

stack1 = stack2
stack2 = stack3
stack3 = stack4
...

---

-I didn't know how to make a function that returned a value, so I just used a global variable called "answer".

-I didn't know how to parse a string, so I just selected (i.e. highlighted) the first letter in the input text box and called the selected letter the "pointer". To advance the "pointer", I would call up the System.Keyboard object and press the right arrow key! I guess I trusted my user to leave the window in focus during the parsing.

Amazingly, the program actually worked. I will never figure out how, but I somehow parsed an input string, converted it from infix to postfix, parsed the postfix expression, and calculated the result without knowing about arrays or return values.

Then, I took a real programming class and thought "you mean you can do that?!" at the start of every chapter.

Man, I wish I still had the source code for that thing. If I ever find it, I'm sure it will be a good laugh looking through and seeing what other clever things I did.

For stories like this, read www.worsethanfailure.com . This site is dedicated for various WTFy stories related to IT. Gives great fun, and is really addictive. For you, CodeSOD series would be most interesting, I think, but check other series also, as well as comments to each entry! :wave:

What wrong with the vector program ?

Quote:

---

What wrong with the vector program ?

---

Two things actually but I have to admit that they weren't apparent at first. The fixed code should be:

Code:

---

#include <iostream>
#include <string>
#include <vector>
#include <numeric>
#include <algorithm>

using namespace std;

int main()
{
        vector<unsigned long long> vec;
        vec.push_back(123456789012ULL);
        vec.push_back(987654321098ULL);

        unsigned long long result = accumulate<std::vector<unsigned long long>::iterator, unsigned long long>(vec.begin(), vec.end(), 0ULL);
        cout << result;
}

---

The funny thing is that gcc warns you about not tacking on "ULL" at the end of the constants while Microsoft's Compiler warns about not using the right template parameters for std::accumulate (well not in a straight-forward manner of course). Unfortunately, neither of those compilers will warn you about both the errors. :)

My story:
I was getting more and more frustrated as to why my physics code wasn't working. I calculated it on paper 3 to 4 times over again and it was supposed to work theoretically. I checked my implementation logic at least 10 times and reimplemented at least 3 variants of it. Finally I spotted the problem and fixed it. It resulted due to a trivial copy-paste error. Combined with the rest of the lengthy and messy code, it just escaped my sight till when I finally tracked down the error to be within a certain range of the code.

I was doing something like this: 1.0f / (a.OneOverMass(), b.OneOverMass());
Where, in fact, I was supposed to do this: 1.0f / (a.OneOverMass() + b.OneOverMass());

The difference was just that an addition got changed to a comma, but it made a huge difference!
Instead of getting the sum of the inverse masses of a and b, I was just getting the inverse mass of b.
This would result in a bigger impulse being applied than necessary, and create instability in the system.