Weird bugs you have encountered

[Slougi]

So I was implementing drag and drop in a Qt widget today.

This worked.

print "original:", addresses
raw = str(pickle.dumps(addresses))
bytes = QByteArray.fromRawData(raw)
print "unpickled before drag:", pickle.loads(str(bytes))

This resulted in a backtrace.

print "original:", addresses
raw = str(pickle.dumps(addresses))
bytes = QByteArray.fromRawData(raw)

Yay for buggy library implementations and bindings Of course, that last picke.loads() call serves no real purpose at all. This one was nice to track down...

 

[smcd]

I had a typo once that killed MinGW / GCC C++ compiler heh,

/*
g++ 3.4.2
templatevirtual.cpp: In function `int main()':
templatevirtual.cpp:45: internal compiler error: in lookup_member, at cp\search.c:1288
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http:\\www.mingw.org\bugs.shtml> for instructions.
*/
#include<iostream>
#include<string>

template<class t>
class Foo
{
	public:
		Foo()
		{
			std::cout<<"Foo("<<(void*)this<<")"<<std::endl;
		}
		virtual ~Foo()
		{
			std::cout<<"~Foo("<<(void*)this<<")"<<std::endl;
		}
		virtual void spitstuff(t val)
		{
			std::cout<<"Foo::spitstuff("<<val<<")"<<std::endl;
		}
};

template <class t>
class Bar : public Foo<t>
{
	public:
		Bar()
		{
			std::cout<<"Bar("<<(void*)this<<")"<<std::endl;
		}
		~Bar()
		{
			std::cout<<"~Bar("<<(void*)this<<")"<<std::endl;
		}
		void spitstuff(t val = "")
		{
			std::cout<<"Bar::spitstuff("<<val<<")"<<std::endl;
		}
};

int main()
{
	Foo<int> foo;
	Bar<std::string> bar;
	// the below line makes g++ 3.4.2 (only one tested) die
	bar.Foo<std::string>.spitstuff("I crash");
	// it should be like this instead:
	// bar.Foo<std::string>::spitstuff("I crash");
	bar.spitstuff("g++!");
	return 0;
}

 

[Toasty]

I had a heck of an annoying bug with a file synchronization app I was working on yesterday. It was a really simple mistake (I mixed up two numbers), but it still compiled and ended up causing inconsistent problems just about everywhere except the actual area where my typo was.

In the function that was supposed to compare two directories for differences (using an arbitrary hash algorithm) I accidentally opened the same directory twice, rather than opening both directories once, and compared the one directory with itself. I used two separate threads to read the files' hash digests, but the internal state of the hash algorithm was stored in the directory class. (I figured, since I'd only be using one thread per directory, it would be efficient to just have one hash state per directory.)

But, since I accidentally goofed and compared a directory with itself (it was as simple as replacing a '1' with a '2' at one spot in my code), both threads were accessing the files in one directory - both threads were making use of the same hash state, and I ended up catching a bunch of exceptions in the hash algorithm class.

So, I spent a good hour or two looking for a bug that didn't exist in the hashing functions I had written. Finally, I figured out that the state of the hashing algorithm was being 'tampered' with. So I tried synchronizing access to the hash algorithm's functions and voila, the exceptions disappeared. It still wasn't producing correct results, but I finally figured out that the problem had something to do with two threads using the same hash state at the same time. I scanned through all my code aimlessly and finally saw it - a little '2' where there was supposed to be a '1'. "I'm so stupid," I thought to myself.

 

[Cyberman]

Spear and Magic numbers ..

Ahh Toasty. My Boss would be giggling and force a code review on you

Well for safety reasons we've started to head toward MISRA code process.

One thing is I am not allowed to use 1's or 2's for ANY array reference. I can do something like this

for(sensor_record_id = sensor_location_first;
 sensor_record_id <=sensor_location_last;
 sensor_record_id++)
{
 printf
  (
  "%s = [%d]\n",
  sensor_name_from_type
   (
   sensor_get_structure(sensor_record_id)->type_information.type
   ),
  sensor_record_id
  );
}

I recomend from now on do NOT use 1 0 2 or any such magic (non enumerated literal type) with anything that references something. It's caused me more stupid mistakes than you can count stars. In my case it could end up someone dying because they might not be warned about something.
So in your case I would suggest

enum directory_locations {
first_directory_identity,
second_directory_indentity
};

Just to be sure what you are comparing when you read the code looking for why something happened or simply just writting the code, you probably could have caught the woopsie before you spent 5 minutes of debugging (you saved 5 minutes using literals which you lost in debugging ).
In my case I have a set of pointers to data structures that I've moved from RAM to ROM so that the data structure locations can't be overwritten by some errant bit of code. Reliability and making fewer bugs I've noticed go hand in hand.
I may not be the best at dealing with C++ (Embedded systems mostly use C due to constraints and instantiation issues) but I have had to debug less of my code or see something go wrong.
In C++ I always try to make things as EXPLICITE and OBVIOUS as possible so while I'm writting the code I don't make simple mistakes.

As for my bug... well I was formating floating point data using an sprintf() function to a data buffer. The buffer kept getting trashed because (cough) I didn't range check the floating point buffer before calling sprintf. In this case someone would see
"2349074.1F"
instead of
" 99F 11:04"
WOOPS!


Cyb

 

[Toasty]

Actually it wasn't a magic number to an array index, it was part of a variable name. My function signature read something like this:

List<Difference> compareDirectories(Directory dir1, Directory dir2)

I called them dir1 and dir2 for lack of any better ideas, and, well, then you know what happens...

 

[Slougi]

I've personally found that calling such variables either one and two, or first and second is better than appending a number. I usually use some sort of list if there are more than two, although this depends on what the function does.

 

[GaryCXJk]

I had a problem trying to figure out multi-imaged TPL files. Everytime I tried to make it work, it failed on me, crashing on me, or not extracting the right data.

Eventually I went and look at the TPL file which I created myself with some amateur hex editing, and found out I had the offsets set up wrong, so it would just read the wrong data. Fixed the offsets, and it worked.

 

[Exophase]

Semi-recently I had a bug in an ARM based 65xx emulator core where one of the instructions was causing things to crash later under certain conditions. As soon as I enabled step debugging this went away. This was all because the interpreter loop relies on flag status and flags were being set incorrectly in that particular opcode handler. But the calls to the debugger were changing the flag status so that the erroneous flag condition would no longer happen. That was a fun one to track down, since I really need the debugger to determine where something's going wrong.

 

[Cyberman]

Semi-recently I had a bug in an ARM based 65xx emulator core where one of the instructions was causing things to crash later under certain conditions. As soon as I enabled step debugging this went away. This was all because the interpreter loop relies on flag status and flags were being set incorrectly in that particular opcode handler. But the calls to the debugger were changing the flag status so that the erroneous flag condition would no longer happen. That was a fun one to track down, since I really need the debugger to determine where something's going wrong.

Isn't the debugger messing with flags a bug as well? It shouldn't do that technically otherwise how do you DEBUG if the flags are being reset?

Cyb

 

[Exophase]

Isn't the debugger messing with flags a bug as well? It shouldn't do that technically otherwise how do you DEBUG if the flags are being reset?

Cyb

Native flags. Not emulated flags.