Bugs of the day, Thursday 2013-03-21

Failed to initialize instance-specific member variable correctly because I was calling the wrong constructor

struct Foo {
  bool m_B;
  Foo(Bar& bar) : m_B(true) { /*do something else with bar*/ }
struct Baz : public Foo {
  Baz(Foo& foo):Foo(foo) {}

Thinking that Baz::Baz(Foo&) was calling the defined construct-from-reference-to-bar constructor that would initialize m_B to a particular state when in fact I was calling the compiler-generated copy constructor that would not.

Yet another case of pay attention-to-what-you’re-doing. The thing that got me this time was that this codebase doesn’t have a lot of construct-from-reference, so led to the trap of if it compiles, it’s probably OK.

Quite possibly this was fallout from yesterday’s the slicing-inheritance bug where I changed inheritance to a pointer-member, but didn’t change the construction call.

Use of uninitialized system

Calling functions in a particular system without having called the appropriate System::Init() function. The results aren’t pretty.

This was caused by carelessness when un-shelving a partial rework of the init and use of the particular system.

Keeping track of where particular code is being called requires extra effort when managing multiple versions of the same files. Clearly, I’m too easy to confuse and need to be more careful, and to work with fewer variations.

In general, checks/asserts in the external interfaces to a system are probably worthwhile to catch this kind of thing a little sooner.

Yet another uninitialized member variable crash

In a rework of a rework of a rework of some code I lost a couple of struct member initializers.

Init to zero, all works as expected. Sigh.

End of day reflection:

Making changes to a previously-working system, it would have been profitable to spend some time to capture the known-good output (and a record of the known-extant bugs) at the start of the process. I spent some time reverting all my changes and re-building to confirm my analysis of these things, which was not the most efficient approach.


Leave a Reply

Your email address will not be published. Required fields are marked *