If you follow the rule of Zero, how will you debug the construction of an object?

Question

Everyone is quick to point out the "Rule of Zero" in code reviews, peer conversations, and Stack Overflow comments/answers.

I am not a believer. I'd like to be. Usually if enough people agree on something enough for it to get its own label and become an idiom, then it is well thought out....

So, let me explain my reason for not believing:

I cannot count the number of times I have been tasked to debug a crash dump from a production crash. While debugging said dump, I can look up and down the call stack and sometimes I have the need to see "When is this class being constructed?" Secondarily, I might need to see "What is its or its members addresses when it is?" This usually leads to some other place in the code after evidence that more instances are being created than should be, or when addresses or sizes are not what is expected.

This could also apply, when I want to see "When is this class being assigned to?"

As such, I've always implement all 5 methods, trivial or not, in order to provide a place to break in future debug sessions while reproducing the conditions in the dump without having to change the source. Without them, there would be no way (easily) to perform the above debugging session.

If you modify source in order to provide a line of code to break on, your crash dump is no longer usable with the source.

Now, some would say that this situation does not arise often enough for them to add more code, and more potential bugs, in the case of trivial constructors and assignment operators. However, I'd argue that one occasion having to explain to your superiors that you have to make another build, redeploy to production, reproduce the crash, and retrieve another dump, in order to even start debugging the problem, is enough to change one's outlook. That is not an enjoyable experience and it has occurred to me a number of times.

So, please make me a believer!

Tell me how I can accomplish the above described debugging session given a crash dump, when there is no line available to break on, after being a good boy and following the "Rule of Zero".

Namely:

1. Break any time any instance of a given class is being constructed without any lines of constructor code to break on.

2. Break any time any instance of a given class is being assigned to without any lines of assignment operator to break on.

I am using Visual Studio, and more specifically Visual Studio 2015.

Answer 1

After much debate, many lunches, posts on various forums, and head scratching, a colleague of mine came up with the following:

In Visual Studio, go to Debug->New Breakpoint->Function Breakpoint and enter the fully qualified name of the compiler generated method you wish to break on. For example Foo::Foo will break in Foo's compiler generated default constructor. We can add Foo::Foo(const Foo &) for its copy constructor, Foo::Foo(Foo &&) for its move constructor, etc. Note that you must also include any namespace. Also note that you can add function names that do not exist. Take note of the opaque red dot in the breakpoints window vs empty circle denoting a point that will not get hit.

After the debugger breaks, we can use the callstack window to identify what it broke on and choose to continue or not. If we wish to inspect then we can open the disassembly window and step (F10) to the point the constructor, copy constructor, assignment, etc is complete. We can look for the "ret" instruction to guide us. When it goes one up the call stack, even in the disassembly window, the name of the method is denoted. We can then switch to Locals and view "this" as normal.

This is, of course, specific to Visual Studio. Other debuggers might have something similar.

Answer 2

Since crash dumps can only be troubleshot with the original binaries and debug symbols generated from the original source code, any suggestions that ask to change the source code, or to recompile, do not help with the present situation (of crash dumps that OP has already received). These suggestions could only improve the prognosis of troubleshooting the crash dumps of future releases of the software.

_{(Rant.) Should I mention that the typical cost to technical support to investigate a non-obvious crash dump involving some kind of data trashing and reconstruction of program and execution state is about $1000 USD? If you can spend one week of work to prevent one crash dump in the future, that seems worth it. I see outsourcing opportunity here (to lower-cost countries) but to let a third-party investigate a core dump means you give away the entirety of the company's tangible software secret.}

---

In general, the ability to read and understand the assembly code shown in the Visual Studio step debugger is a requirement for one to work with crash dumps.

The choices are:

• Acquire the ability to handle this task yourself.
  • Learn to read assembly code and techniques for reconstructing an understanding of the program state and the path of execution prior to the crash when given a crash dump.
• Let your supervisor know so that the task can be reassigned
• Delegate this task to someone else

---

Techniques that I use when faced with same situation.

The first rule before working on a crash dump is to try to reproduce the same crash yourself. If you can recreate the conditions that lead to a crash, it enables you to troubleshoot a live instance of the crashing program (i.e. you can step-execute it), as opposed to a frozen instance (i.e. a crash dump which does not allow you to step-execute).

If a function is known to have been inlined, then I try to locate all of the callers (technically "call sites"), and set breakpoints there. If even the callers are inlined, I will chase their parent callers until I find call sites that aren't inlined.

Note that, for the purpose of locating all possible call sites, you can do that on a rebuild of slightly modified source code. The knowledge of "all possible call sites" is a knowledge you can take away from one version of source code, and most of that knowledge is still applicable on the crash dump you are working on.

To track down a struct, it is necessary to know its address. A typical way in which the address of a struct is revealed in disassembly code is when that address was passed into a function call.

---

Are there problems with the "rule of zero"?

I agree that it is often misapplied (and would be better if this issue is fixed in the source code for future releases), and shares my own experience.

---

Personally I do follow the "rule of three" or "rule of five" for most C++ classes if at least one of the constructor / destructor is not trivial default.

I do this for two reasons.

The first reason is similar to yours. When a constructor is not trivial default, that means there is some "code" that the compiler must generate for you; these generated code may need to call some other code, such as the constructors for some members of the class. If those other code were written by you, you will want to be able to debug them. Providing a user-defined constructor makes this task easier.

The second reason is that, when a constructor is implicitly declared, in some situations it can cause issues when I try to store that type into an STL vector. The superficial reason was related to the problem of incomplete types, but since I'm not certain about the underlying reason and it's not related to this question so I will stop here.

---

However, providing a user-defined constructor does not always turn off inlining for these methods - the compiler may inline some of them e.g. the constructor anyway. To truly prevent inlining, you would use declspec(noinline) with MSVC.

The ability to use disassembly debugging on optimized builds (builds made with "Release" configuration) depends on both inlining and the version of MSVC. Visual C++ 2017 has better handling for maintaining the map between disassembly address and line-of-code location for inlined functions.

---

Sometimes, the disassembly debugger skipped over an empty constructor, because it is truly empty. A C-compatible "POD" type is typically believed to be initialized with memset(p, 0, sizeof(*p)) or a sequence of XOR RAX, RAX; MOV [...], RAX which are effectively zero-filling instructions. In some cases they aren't zero-filled at all, i.e. there aren't any instructions. The disassembly debugger cannot stop on non-existent disassembly addresses.

---

Just as a offhand remark, I find that:

• The destructor of a type appears to generate more "stuff that are visible in disassembly". Most noticeable is if the destructor is called as part of a deletion on dynamic memory (delete). In the disassembly, one will see an actual function call to an address associated with some_type::scalar deleting destructor. Once a module (EXE or DLL) has been loaded into the process space, one can set a breakpoint at its disassembly address.

• I tend to follow two-phase initialization in my project, due to reasons which aren't pertinent to this question. But because of this project guideline, I find that errors tend to be thrown not from the constructor, but instead from the second function which does the heavy-lifting.

• I also use exceptions with string messages. If your project doesn't use exceptions, you may consider error logging as an alternative for capturing details about errors.

---

The key to debugging problems with a struct is to know (record) its address with certainty. There are many techniques. However, a discussion of these techniques may make the discussion too broad.

Answer 3

The inevitable result of relying on many abstractions is the loss of ability to do certain things. You can put a breakpoint in a virtual function that gets called, but you can't put a breakpoint on the virtual dispatch logic itself. That is, you can't find out when anyone calls a base class's virtual function, since the function that gets called could be any of the derived class overrides.

The same goes here with special member functions. The compiler generated code for you, and there's nowhere for you to put a breakpoint. That's life.

So, you can either choose the advantages of the Rule of Zero (ease of maintenance due to DRY, ease of implementation (have you ever forgotten to check for self-assignment?), etc) or take the debuggability of manually writing the function. Or you can just do both: when you want to put a breakpoint in a special member function, write the special member function then. And then, remove it after you're done debugging.

It should also be noted that the advantages of using compiler-generated functions involve things that you cannot get otherwise. For example, trivial copyability. You cannot write a trivial copy constructor; if you provide a copy constructor implementation, even if it does exactly what the compiler one would, the type is no longer TriviallyCopyable.

And that's not something you should give up lightly.

Answer 4

In my opinion, the "rule of zero" is not a rule. It's a design pattern. You don't win points for using it and you don't get penalized by the Rule of Zero Police for disobeying it*; but it might make your code easier to read and maintain.

---

In my opinion, the "rule of zero" does not forbid you to write a constructor that performs some logging function or, a constructor that exists so that you can set a breakpoint on it. A constructor only violates the rule if it performs some explicit initialization of the object's members.

---

* _{Or, maybe they do. Consider looking for a different employer if that is the case.}