在Microsoft Visual C ++中调试共享指针

Question

Is there a way in Microsoft Visual C++ to have a view of the points in the code from which a shared pointer is referenced?

Eg:

class MyClass;
class MyDerClass : public MyClass;
boost::shared_ptr<MyClass> pmc1 = new MyClass;
boost::shared_ptr<MyClass> pmc2 = pmc1;
boost::shared_ptr<MyDerClass> pmc3 = pmc1;
...
delete pmc1;   // object still around until pmc2 and pmc3 are deleted

Can I know which pointers (at the source code level) still point to that object?

Answer 1

I don't think this is possible. You can inspect the reference count of one shared_ptr to see how many references to the underlying object are outstanding, but that is not quite what you are after.

In order to know which outstanding instances of shared_ptr<T> point to the same T* , you would need to augment or re-implement shared_ptr<> to track (presumably only in a debug build) all shared_ptr<> instances in a static global thread-safe map. That doesn't quite get you what you want, but if you also add a string (a "label") argument to each shared_ptr<> constructor (perhaps using __FUNCTION__ and some macroizing for context labeling), you can at least dump the map at a certain point in time and review what is pointing to what.

It may be that you don't really want to inspect all of this in the debugger, but perhaps there are certain situations where you want an assertion and detailed report of a problem? Like "when I get here, I should be holding the last reference to this object, and if that's not true I want to raise an assertion and report what else is holding one"? If that's the case, you might be able to get there by enabling some detailed object-by-object logging as references are added and removed.

We had a similar issue regarding mutexes, namely that we wanted to know if there were potential deadlock situations resulting from code paths that could lock and hold two or more mutexes in different orders. We ended up building a "safe mutex" that tracked all mutex-locked-order tuples in a global data structure, and logic to detect incompatible orderings. This was too slow to production, but works nicely in a debug build. It could also tell us if a given thread had a mutex locked, to flag issues like holding mutexes during RPC calls, which an be a bad idea in some situations.