{"id":1210,"date":"2013-04-07T04:01:13","date_gmt":"2013-04-06T18:01:13","guid":{"rendered":"http:\/\/brnz.org\/hbr\/?p=1210"},"modified":"2013-04-07T04:01:13","modified_gmt":"2013-04-06T18:01:13","slug":"bug-of-the-day-tuesday-2013-04-02","status":"publish","type":"post","link":"https:\/\/brnz.org\/hbr\/?p=1210","title":{"rendered":"Bug of the day, Tuesday 2013-04-02"},"content":{"rendered":"

Implicitly finding bugs in other people’s code<\/h3>\n

A crash was reported with a call stack leading to some code I’d been making changes to a week ago (code that previously featured in <\/span>Unexpected use of class<\/a>\u00a0and\u00a0<\/span>Initialized, but not in the right order<\/a>).<\/span><\/p>\n

The code I’d changed now looks something like this:<\/p>\n

struct Foo : public Baz {\r\n\u00a0 Bar* m_Bar;\r\n  Foo() : m_Bar(NULL) {}\r\n  void SetBar(Bar* bar) { m_Bar = bar; }\r\n\r\n\u00a0 virtual void Destroy() override;\r\n};<\/pre>\n
The cause of the crash was something trying to make use of a null m_Bar<\/strong> member of a Foo<\/strong> object.<\/p>\n
With regard to the previous crashes I’d encountered, my first suspicion that this was an object that was somehow being created in a way that had not correctly initialized the m_Bar<\/strong>. Checking the circumstances of the crash (the reporter was able to find a specific cause, which was a great help), I was unable to see a way that this object could have been created with m_Bar<\/strong> remaining null.<\/p>\n
Sidebar: A way in which my debugging skills have improved in the last year<\/h3>\n
I have identified the following tendency in my thinking: see a bug, take a guess at the cause, and then look for that cause in the following way:<\/p>\n
1. Examine some part of the codebase.
\n2. If expected cause not found, goto 1.<\/p>\n
So if I guessed the wrong cause, I get stuck in a loop: “It must be X, but I haven’t yet found how X could happen — I must look harder!”<\/p>\n
Part of this came, I think, from a degree of insecurity about my own ability to read and understand code: “the bug is in here, but I must have missed something”<\/p>\n
What I’ve realized in the past year is that my code reading skills aren’t that bad — if I haven’t found the cause I’m looking for, it’s more likely that I’m looking for the wrong cause. Particularly, I am now able to approach a problem with a hypothesis about the cause, and can more clearly identify when I’ve found some information that invalidates that hypothesis and I should be looking for a different cause.<\/p>\n
In the context of this bug, validating how the object was being created and seeing that the codepath would always validly initialize m_Bar<\/strong> meant that the bug was not in the initialization — it must be somewhere else.<\/p>\n
The other nuller<\/h3>\n
So something else was setting m_Bar<\/strong> to null after the initialization. There is one other place where that happens…<\/p>\n
  virtual void Destroy() {\r\n\u00a0 \u00a0 if( m_Bar != NULL) {\r\n    \u00a0 m_Bar->Destroy();\r\n      m_Bar = NULL;\r\n    } else\r\n\u00a0 \u00a0 \u00a0 HARD_TO_MISS_NOTIFICATION( USEFUL_WARNING_37 );\r\n\u00a0 }<\/pre>\n
So, it looks like there’s a good chance that this object has had its Destroy()<\/strong> called, and looking through the code, it becomes clear that this is indeed what has happened.<\/p>\n